<p dir="ltr">Ah, for this use case, having to wait for dns timeout sucks. :(</p>
<p dir="ltr">Adding an asynchronous DNS resolver would be possible, but I am afraid it won't make it to our schedule soon enough to solve your problem. I see two solutions:</p>
<p dir="ltr">1) what about you or a colleague submit a patch? :)</p>
<p dir="ltr">2) validate the hostname before generating it into the configuration</p>
<p dir="ltr">3) hack the syslog-ng startup script and validate it before syslog-ng is launched with the erroneous hostname</p>
<p dir="ltr">Ops, that was three not two, but you get the idea.</p>
<div class="gmail_quote">On Aug 24, 2015 7:27 PM, "David Hauck" <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, August 24, 2015 10:10 AM, <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a> wrote:<br>
> The destinations don't have dns resolution problems. They resolve<br>
> their target name once and at every reconnect. On the source side you<br>
> have a potential name lookup for every message (if uncached of course).<br>
<br>
Understood, but see below.<br>
<br>
> Or you mean that the target server cannot be resolved?<br>
<br>
Correct. These target destinations are configured by administrators and the DNS failures may or may not be seen in a timely fashion (so the continual reconnects will result in frequent blockage).<br>
<br>
> Why not add it<br>
> to /etc/hosts?<br>
<br>
This isn't an option when the operator simply gets the name wrong (independent of whether the host is actually online and DNS resolvable) ;).<br>
<br>
> Initiating a reconnect is handled in the main thread,<br>
> thus name resolution of the target server would block other threads as well.<br>
<br>
By other do you mean all other threads? If not, which ones? What operations are suspended during the time of the blocked DNS resolution (note: typical resolver configuration is to retry 2-3 times with retry timeouts set to ~10s - so the total blockage time on a failed DNS lookup could be significant)?<br>
<br>
> The basic problem of name resolution is on the source side though,<br>
> there each incoming message can have an associated dns cache miss but<br>
> that's delegated to the workers.<br>
<br>
OK, understood for the source, but I'm still trying to determine the exact effect on destinations that fail to resolve...<br>
<br>
> On Monday, August 24, 2015 7:31 AM, <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a><br>
> wrote:<br>
>> sources/destinations are worked on by a set of worker threads, which<br>
>> are not dedicated to a source or destination.<br>
>><br>
>> DNS resolution happens at the input side, so if you have multiple log<br>
>> statements, it will only happen once, right after reception, on the<br>
>> input side.<br>
>><br>
>> however, if you only have one udp() source, that will only use one<br>
>> worker at a time, so if you have multiple threads the others will not<br>
>> be affected.<br>
>><br>
>> hope this helps.<br>
><br>
> ;) Not sure. First off, my UDP DNS resolution concern is in relation<br>
> to a<br>
> *destination* definition.<br>
><br>
> destination d_NAaudit_Prio { file("/var/log/zzz/audit_log"<br>
> template(t_NAFormat_Prio)); udp("testing" port(514)<br>
> template(t_NAFormat_Prio)); };<br>
><br>
> This same destination is used in several log statements, the main one<br>
> of which is in a fairly complex log statement with multiple junction<br>
> definitions (see the genesis of this in the following mailing list<br>
> thread:<br>
> <a href="https://lists.balabit.hu/pipermail/syslog-ng/2014-April/021330.html" rel="noreferrer" target="_blank">https://lists.balabit.hu/pipermail/syslog-ng/2014-April/021330.html</a>).<br>
><br>
> So it isn't entirely clear to me how a statement definition like this<br>
> results in a specific thread breakdown... Would isolating this<br>
> destination to its own thread be as simple as adding "threaded" to the<br>
> flags option for this destination (and then any of the referenced "log"<br>
> statements would be running in their own threads), or does this<br>
> happened by default (in v3.6.x)?<br>
><br>
> Apologies if I'm missing something obvious here ;).<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: <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>
</blockquote></div>