If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example, nobody can log in.
This happens because once the /dev/log buffer fills, the syslog()
glibc function blocks.
This is a problem for us in Real Life because named and syslogd are
deadlocking while trying to talk to each other. On our loghost,
syslogd needs to do reverse name lookups while named needs to call
syslog(). When traffic gets heavy all around, the deadlock is
triggered, and it is quite unpleasant. We are about to configure
named to use flat files instead of syslog, but that feels more like a
workaround than a fix.
I am not sure whether this is a glibc bug or a kernel bug. I have
used netstat and the glibc sources to confirm that glibc is using a
SOCK_DGRAM Unix socket to send to /dev/log. I thought DGRAM sockets
were supposed to drop packets on the floor instead of blocking. But
perhaps I am wrong and glibc is supposed to be explicitly marking the
socket as non-blocking.
Regardless of whose bug it is, I suggest that it needs to be fixed.
To my knowledge, other Unix systems do not behave this way; they
simply drop messages when syslogd is not responding. IMO, that is
correct behavior.
- Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
