Messages in this thread |  | | From | (Patrick J. LoPresti) | Subject | syslog() blocks on glibc 2.1.3 with kernel 2.2.x | Date | 23 Oct 2000 12:31:52 -0400 |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |