krshd hangs in linux nightly testing
authorKen Raeburn <raeburn@mit.edu>
Fri, 29 Aug 2003 07:09:48 +0000 (07:09 +0000)
committerKen Raeburn <raeburn@mit.edu>
Fri, 29 Aug 2003 07:09:48 +0000 (07:09 +0000)
commit8b1bc6112f43e707d007f8b82d6c8c50775c4328
tree214ddb5232b1d7273267d00806a336de96e06641
parent6c1055cad98795ce650c7a8f89b6139fbad226a3
krshd hangs in linux nightly testing

A typical stack trace:

#0  0xffffe002 in ?? ()
#1  0x420da75f in syslog () from /lib/tls/libc.so.6
#2  0x0804ad06 in cleanup (signumber=15) at krshd.c:567
#3  <signal handler called>
#4  0xffffe000 in ?? ()
#5  0x4202774e in sigaction () from /lib/tls/libc.so.6
#6  0x0804ac82 in cleanup (signumber=1) at krshd.c:548
#7  <signal handler called>
#8  0xffffe002 in ?? ()
#9  0x4202774e in sigaction () from /lib/tls/libc.so.6
#10 0x420daa21 in vsyslog () from /lib/tls/libc.so.6
#11 0x420da75f in syslog () from /lib/tls/libc.so.6
#12 0x0804b670 in doit (f=3, fromp=0xbfffda50) at krshd.c:1313
#13 0x0804ab87 in main (argc=11, argv=0xbfffdb34) at krshd.c:459
#14 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

Yes, we're calling syslog from inside a signal handler.  Yes, this is
bad.  And from some poking about that I did earlier, it appears that
there's some locking code in vsyslog which may be deadlocking in the
nested call.  And this usually seems to happen when logging the "shell
process completed" message.

This is a quick patch to switch off the signal handlers before logging
that message.  I suspect the breakage happens earlier, though, so this
might not fix the bug, just maybe move it around a little.

* krshd.c (ignore_signals): Split out from cleanup().
(doit): Call it when the shell process has completed, before calling syslog.

ticket: new
status: open

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@15800 dc483132-0cff-0310-8789-dd5450dbe970
src/appl/bsd/ChangeLog
src/appl/bsd/krshd.c