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

[Scheidler, Balázs]

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.
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20150824/6f80afc7/attachment-0001.htm