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

David Hauck davidh at netacquire.com
Mon Aug 24 19:26:46 CEST 2015


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
>


More information about the syslog-ng mailing list