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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:21 EST