Messages in this thread |  | | Date | Mon, 23 Oct 2000 15:53:09 -0400 (EDT) | From | Ricky Beam <> | Subject | Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x |
| |
On 23 Oct 2000, Patrick J. LoPresti wrote: >Ulrich Drepper <drepper@redhat.com> writes: >> If anything has to be changed it's (as suggested) the configuration >> or even the implementation of syslogd. Make it robust. > >OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM. >If I wanted reliable syslogging, it would be listening on it as a >SOCK_STREAM. Maybe I care more about performance and backwards >compatibility than reliable syslogging. But whatever my reasons, my >connection to syslogd is already unreliable and therefore *should not >block*.
You obviously don't understand the communication channel being used. "/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable.
Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM and watch it fail. (syslog wasn't invented yesturday.)
I would suggest disabling name resolution for syslog, but that's an ugly option. There's no way to stop a glibc system from doing a DNS query for a reverse lookup. HOWEVER, you can set the DNS timeout to 1 second and set the resolver options to prevent recursion (answer from cache only.)
--Ricky
PS: Technically, this is not a lockup. syslogd should eventually timeout waiting for the DNS query and go about it's business. Of course, that may be upwards of 45 seconds -- very annoying.
- 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/
|  |