<div dir="ltr">Hi there,<br>we are using syslog-ng 3.6.4 on Linux.  we had an incident where the network port used for remote logging was inadvertently disabled for a couple hours, and during this time a critical process which logged via syslog() calls experienced threads hanging for seconds to minutes at a time.  <div><br>after some investigation and reproduction efforts, it looks like the problem is a combination of:<br>- remote logging to server specified by hostname (vs. IP)<br>- loss of management interface (e.g. that used for syslog traffic and DNS resolution)<br>- log rotate triggering syslog-ng reload<br><br>when I reproduce the problem (seems to take some considerable amount of logging load and a minute or so), I can see that writes to /dev/log hang:<br>root@escort-ct0:/etc# strace -ttT logger test<br>^C<br>19:38:46.064830 execve("/usr/bin/logger", ["logger", "test"], [/* 26 vars */]) = 0 <0.000135><br>...<br>19:38:46.069757 socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 1 <0.000015> <br>19:38:46.069806 connect(1, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0 <0.000010> <br>19:38:46.069850 sendto(1, "<13>Mar 20 19:38:46 root: test", 30, MSG_NOSIGNAL, NULL, 0) = 30 <11.627190> <br>19:38:57.697110 close(1)= 0 <0.000490><div><br>meanwhile I see the main thread timing out name resolution:<br>19:48:18.214182 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=148, ...}) = 0 <0.000008><br>19:48:18.214234 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 31 <0.000012><br>19:48:18.214279 connect(31, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.15.83.11")}, 16) = 0 <0.000024><br>19:48:18.214332 poll([{fd=31, events=POLLOUT}], 1, 0) = 1 ([{fd=31, revents=POLLOUT}]) <0.000006><br>19:48:18.214370 sendto(31, "\343\235\1\0\0\1\0\0\0\0\0\0\rescdev-syslog\3dev\vpurestorage\3com\0\0\1\0\1", 51, MSG_NOSIGNAL, NULL, 0) = 51 <0.000047><br>19:48:18.214444 poll([{fd=31, events=POLLIN}], 1, 5000) = 0 (Timeout) <5.005040></div><div><br>this repeats with the other DNS servers configured.  </div><div><br>I cannot reproduce the issue if I configure an IP instead of hostname for the syslog server. </div><div><br>we are using UDP and no flow-control configuration, with the expectation that syslog() will never block.  and, indeed, until the reload, it works as expected.  however, after reload I guess we re-establish the socket for the remote connection, requiring us to resolve the hostname; I don’t pretend to understand how this ultimately backs up processing of /dev/log (note that internal() and kernel messages are coming through just fine during this time).</div><div><br>I guess my question is whether this is a known/expected issue, and/or if there’s a resolution other than specifying remote syslog servers by IP or hardcoding the name resolution in /etc/hosts and pointing to that with dns-cache-hosts().  basically, I’d like syslog-ng to simply give up if it can’t resolve remote syslog server hostnames, rather than allow this to interfere with servicing of /dev/log, with ramifications to callers.<br><br><br>thanks in advance,<br>nathan</div></div></div>