<div dir="ltr"><div>Hi,<br><br></div>DNS resolution happens in the main thread while reloading, so indeed the only resolution is now to:<br><br><ol><li>use IP address in the config</li><li>hard-code the name in /etc/hosts</li></ol><p>We used to resolve the name only during startup, but another use-case is to handle IP changes when reloading, which conflicts with your use-case. It would also be possible to add an asynchronous DNS resolution into syslog-ng and do DNS resolution after being initialized, but that's far from a trivial effort, which I can't undertake right now.<br></p></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <br>Bazsi<br></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 18, 2017 at 12:31 AM, Nathan Parrish <span dir="ltr"><<a href="mailto:nparrish@purestorage.com" target="_blank">nparrish@purestorage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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:<a href="tel:(46)%20064%20830" value="+3646064830" target="_blank">46.064830</a> execve("/usr/bin/logger", ["logger", "test"], [/* 26 vars */]) = 0 <0.000135><br>...<br>19:38:<a href="tel:(46)%20069%20757" value="+3646069757" target="_blank">46.069757</a> socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 1 <0.000015> <br>19:38:<a href="tel:(46)%20069%20806" value="+3646069806" target="_blank">46.069806</a> connect(1, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0 <0.000010> <br>19:38:<a href="tel:(46)%20069%20850" value="+3646069850" target="_blank">46.069850</a> sendto(1, "<13>Mar 20 19:38:46 root: test", 30, MSG_NOSIGNAL, NULL, 0) = 30 <11.627190> <br>19:38:<a href="tel:(57)%20697%20110" value="+3657697110" target="_blank">57.697110</a> 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.<wbr>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\<wbr>rescdev-syslog\3dev\<wbr>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>
<br>______________________________<wbr>______________________________<wbr>__________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/<wbr>mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/<wbr>support/documentation/?<wbr>product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/<wbr>syslog-ng-faq</a><br>
<br>
<br></blockquote></div><br></div>