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.


To generate a diff of this commit:



	cvs diff -r5.379 -r5.380 krb5/src/appl/bsd/ChangeLog
	cvs diff -r5.100 -r5.101 krb5/src/appl/bsd/krshd.c