Ok, will try that. Hmm...
Looking at the glibc code, I can see that code is present. Looking
at strace output I could see it get a SIGPIPE, it did a close(), and
then my strace segfaulted. Feh.
Reattaching strace doesn't get me any more output nor does it unstick.
However, if I go into gdb, look at the process (load it up, do a `where'
and bail out), and rerun strace that seems to do the trick and I get
syslog output (to the daemon) again and strace is showing activity.
Probably just partially wedged and stuck but gdb manages to interrupt
something passively enough that it doesn't crash (EINTR without signal?).
dhcpd will crash it if you send it a SIGPIPE and it isn't in syslog(),
so I wonder if it is wedged in the kernel or ignoring other signals
while it is wedged in elsewhere in glibc.
I should have a dhcpd that I can link against a glibc compiled with
`-g' (staticly) and run gdb on that. Maybe that will tell me where it
is getting wedged after catching the SIGPIPE.
> Try tracing syslogd and see if it's receiving anything. (The mark
> messages are done by a timer, if the receive pipe is hosed in-kernel
> those will still happen.)
I can't say. It doesn't *look* like it is receiving anything on the
UNIX socket that dhcpd is using, but it is certainly receiving stuff on
other UNIX sockets (logger messages as well as sendmail output) while
dhcpd is wedged.
--- john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/