[lkml]   [2000]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Ulrich Drepper <> 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

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.)


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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.123 / U:2.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site