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

0 files changed, 0 insertions, 0 deletions