NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

lib/54527: syslogd hangs when forwarding logs to a IPv6 host that is down



>Number:         54527
>Category:       lib
>Synopsis:       syslogd hangs when forwarding logs to a IPv6 host that is down
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 05 22:05:01 +0000 2019
>Originator:     Anthony Mallet
>Release:        -current
>Organization:
>Environment:
NetBSD 9.99.10 (CACTUS) #0: Sun Aug 25 22:06:15 CEST 2019 amd64
>Description:
syslogd deadlocks when it sends a UDP log line to a IPv6 remote host
that is down. It appears to hang on:

(gdb) where
#0  0x00007f7ff5f338ba in recvfrom () from /usr/lib/libc.so.12
#1  0x0000000000207e48 in dispatch_read_finet (fd=9, event=2, 
    ev=0x7f7ff7ee3380) at /usr/src/usr.sbin/syslogd/syslogd.c:802

Before that, it correctly sends the log with no error:
2019-09-05T23:20:47.331842+02:00:/usr/src/usr.sbin/syslogd/syslogd.c:udp_send:2588      udp_send(f=0x7f7ff7be1800, line="<11>Sep  5 23:20:47 cactus tho: x", len=33) to dest.

On the network one can see the ICMP6 neighbor solicitation packets that 
are not replied. And after that, for some reason, the sending socket is
marked as readable by libevent and syslogd tries to read from it.
The socket is actually not readable, so the recvfrom() blocks forever.

This does not happen if the remote host is up. Nor if it's down and syslogd uses its IPv4 address.

The problem is not new, I've be experiencing this since at least December 2018 (but I only recently discovered the real cause).

>How-To-Repeat:
Pick up an unused IPv6 address on the local network and:
# echo 'user.error @ipv6.host.down' >> /etc/syslogd.conf
# syslogd -d
# logger -p user.error x

syslogd should become unresponsive after a few seconds.

>Fix:
I have no idea if the socket is expected to become readable in this situation.
A possible workaround would then be to mark is as non-blocking?



Home | Main Index | Thread Index | Old Index