[syslog-ng] "Error resolving hostname" for UDP Destination

[David Hauck]

On Monday, August 24, 2015 1:50 PM, syslog-ng-bounces at lists.balabit.hu wrote:
> Ah, for this use case, having to wait for dns timeout sucks. :(

;)
 
> 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:
> 
> 1) what about you or a colleague submit a patch? :)
> 
> 2) validate the hostname before generating it into the configuration
> 
> 3) hack the syslog-ng startup script and validate it before syslog-ng 
> is launched with the erroneous hostname
> 
> Ops, that was three not two, but you get the idea.

I get the idea :). I'll ponder this a bit more, thanks for all your thoughts up to this point...
 
> On Aug 24, 2015 7:27 PM, "David Hauck" <davidh at netacquire.com> wrote:
> 
> 
> 	On Monday, August 24, 2015 10:10 AM, syslog-ng-bounces at lists.balabit.hu
> wrote: 	> The destinations don't have dns resolution problems. They
> resolve 	> their target name once and at every reconnect. On the source
> side you 	> have a potential name lookup for every message (if uncached
> of course).
> 
> 	Understood, but see below.
> 
> 	> Or you mean that the target server cannot be resolved?
> 
> 	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).
> 
> 	> Why not add it
> 	> to /etc/hosts?
> 
> 	This isn't an option when the operator simply gets the name wrong 
> (independent of whether the host is actually online and DNS
> resolvable) ;).
> 
> 	> Initiating a reconnect is handled in the main thread,
> 	> thus name resolution of the target server would block other threads 
> as well.
> 
> 	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)?
> 
> 	> The basic problem of name resolution is on the source side though, 	>
> there each incoming message can have an associated dns cache miss but 	>
> that's delegated to the workers.
> 
> 	OK, understood for the source, but I'm still trying to determine the 
> exact effect on destinations that fail to resolve...
> 
> 	> On Monday, August 24, 2015 7:31 AM,
> syslog-ng-bounces at lists.balabit.hu 	> wrote: 	>> sources/destinations
> are worked on by a set of worker threads, which 	>> are not dedicated to
> a source or destination. 	>> 	>> 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. 	>> 	>> 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. 	>> 	>> hope this helps. 	> 	> ;) Not sure. First off, my UDP
> DNS resolution concern is in relation 	> to a 	> *destination*
> definition. 	> 	> destination d_NAaudit_Prio {
> file("/var/log/zzz/audit_log" 	> template(t_NAFormat_Prio));
> udp("testing" port(514) 	> template(t_NAFormat_Prio)); }; 	> 	> This
> same destination is used in several log statements, the main one 	> of
> which is in a fairly complex log statement with multiple junction 	>
> definitions (see the genesis of this in the following mailing list 	>
> thread: 	>
> https://lists.balabit.hu/pipermail/syslog-ng/2014-April/021330.html). 	>
> 	> So it isn't entirely clear to me how a statement definition like this
> 	> results in a specific thread breakdown... Would isolating this 	>
> destination to its own thread be as simple as adding "threaded" to the
> 	> flags option for this destination (and then any of the referenced
> "log" 	> statements would be running in their own threads), or does this
> 	> happened by default (in v3.6.x)? 	> 	> Apologies if I'm missing
> something obvious here ;). 	>
> __________________________________________________________ 	>
> ______________ ______ Member info: 	>
> https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: 	>
> http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: 	>
> http://www.balabit.com/wiki/syslog-ng-faq 	>
> 
> __________________________________________________________
> ______________ ______ 	Member info:
> https://lists.balabit.hu/mailman/listinfo/syslog-ng 	Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng 	FAQ:
> http://www.balabit.com/wiki/syslog-ng-faq
> 
>