<div dir="ltr"><div><div><div><div><br></div>sources/destinations are worked on by a set of worker threads, which are not dedicated to a source or destination. <br><br></div>DNS resolution happens at the input side, so if you have multiple log statements, it will only happen once, right after reception, on the input side.<br><br></div>however, if you only have one udp() source, that will only use one worker at a time, so if you have multiple threads the others will not be affected.<br><br></div>hope this helps.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-- <br>Bazsi<br></div></div></div>
<br><div class="gmail_quote">On Mon, Aug 24, 2015 at 4:27 PM, David Hauck <span dir="ltr"><<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Saturday, August 22, 2015 10:29 AM, <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a> wrote:<br>
> Syslog-ng doesn't use an asynchronous dns resolver, but rather it uses<br>
> the libc one as it wants to keep the ordering of messages.<br>
><br>
> However it uses an inprocess DNS cache, that should mitigate most dns<br>
> latency issues as hosts that generate logs should already be in the<br>
> cache anyway.<br>
><br>
> If you can't trust that the dns will work, just disable dns resolution<br>
> eg use-<br>
> dns(no) or use persist-only dns caching and populate /etc/hosts with<br>
> those you want to see with names.<br>
><br>
> <a href="https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-la" rel="noreferrer" target="_blank">https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-la</a><br>
> te st-guides/en/syslog-ng-ose-guide-admin/html/example-local-dns.html<br>
<br>
</span>Great, the above all sounds fine.<br>
<br>
And, yes, the edge condition I'm considering is a UDP destination with a failing DNS lookup (see below).<br>
<span class=""><br>
> With regards to dns stalling all sources, no its not as long as<br>
> syslog-ng is running in threaded mode. Only the affected worker is<br>
> stalled the others will continue.<br>
<br>
</span>By "affected worker" do you mean the source or the destination. Hopefully this is the latter as I have many "log" definitions (all with the same source and all tied various destinations. Only some of these are configured with udp destinations that fail DNS lookup. What exactly doesn't/does get blocked here?<br>
<div class="HOEnZb"><div class="h5"><br>
> On Aug 22, 2015 5:37 PM, "David Hauck" <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>> wrote:<br>
><br>
><br>
> On <a href="mailto:yslog-ng-bounces@lists.balabit.hu">yslog-ng-bounces@lists.balabit.hu</a>] On Behalf Of Scheidler,,<br>
> <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a> wrote: > Earlier syslog-ng<br>
> immediately exited at startup, now it is considering > dns resolution<br>
> errors just like connection failures so time-reopen applies.<br>
><br>
> OK, thx.<br>
><br>
> BTW, I was reading about the DNS resolver blocking the logger (during<br>
> resolutions, which, in situations where the lookup fails, could result<br>
> in significant time). What does this mean exactly? Are all<br>
> destinations/sources blocked during this time?<br>
><br>
> > Time-reopen defaults to 60 seconds as I remember as well and I<br>
> can't remember any patch that would have changed it.<br>
><br>
> Thx also - I did locate my configuration setting for this and see<br>
> that the distribution I'm using resets this default to 10s (so<br>
> everything's working fine here).<br>
><br>
> > On Aug 22, 2015 1:01 AM, "David Hauck" <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>> wrote:<br>
> > > > Hi Fabien, > > On Monday, June 15, 2015 7:08 AM,<br>
> I wrote: > On Monday, June 15, 2015 > 12:50 AM Fabien Wernli<br>
> wrote: >> Hi David, >><br>
>>> On Fri, Jun 12, 2015<br>
> > at 05:09:03PM +0000, David Hauck wrote: >>> Starting syslog-ng:<br>
> Error > resolving hostname; >>> host='test.nacc.netacquire.dom' Error<br>
> > initializing message pipeline; >>> >>> Unfortunately, this<br>
> results in > the entire process failing to start. >> >> This<br>
> looks a hell lot like > a resolved issue [1] on github >><br>
> >> [1] > <a href="https://github.com/balabit/syslog-ng/issues/318" rel="noreferrer" target="_blank">https://github.com/balabit/syslog-ng/issues/318</a> ><br>
>> Yes, indeed! And<br>
> > this looks to have been included in v3.6.3 - I'll give this a try. ><br>
> > I've finally had a chance to test this and see that it indeed<br>
> fixes > outright error. However, I now see the following messages<br>
> appear every 10s: > > 20150821 15:54:37.994 err<br>
> syslog(syslog-ng):Error resolving hostname; host='tester' ><br>
> 20150821 15:54:37.994 err syslog(syslog-ng):Initiating connection<br>
> failed, reconnecting; time_reopen='10' > > Is there a way to<br>
> change the timeout? Is this the time-reopen global > option? Besides<br>
> DNS lookup retries, what other operations are subject > to this<br>
> timeout? Finally, the default (3.7) OSE documentation indicates the<br>
> time-reopen default is 60s (not 10s like I'm seeing). > ><br>
> Thanks, > -David > ><br>
> __________________________________________________________ ____________<br>
> > __ ______ Member info: ><br>
> <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a> Documentation: ><br>
> <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a> FAQ: ><br>
> <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a> > ><br>
><br>
> __________________________________________________________<br>
> ______________ ______ Member info:<br>
> <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a> Documentation:<br>
> <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a> FAQ:<br>
> <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
><br>
><br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/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/support/documentation/?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/syslog-ng-faq</a><br>
<br>
</div></div></blockquote></div><br></div>