On Mon, 2011-10-17 at 15:26 +0200, Heiko Gerstung wrote:
Hi!
I am using syslog-ng for my network appliance and came across a problem with unresolved destination hosts. But first of all I have to say that from all the syslog daemons I looked at, syslog-ng really stands out as the most versatile and flexible solution. So, thank you for this great piece of software!
In my configuration it is possible to specify a number of remote syslog servers, to which my device forwards all log entries via TCP or UDP/514 in addition to logging everything to local files (/var/log/messages etc.). Now, when a customer enters an unresolvable hostname, syslog-ng does not start at all and therefore the whole system is without a syslog daemon.
My current workaround is to try and resolve the configured hostnames myself and only write them to the generated syslog-ng.conf file when this succeeds, but I wonder if there is no configuration option or commandline switch that prevents syslog-ng from completely stopping to work when it cannot resolve a hostname.
And, is this really the intended default behavior? On my system (and on almost every other system I assume), syslog-ng starts long before network connectivity is available in order to provide logging services during the boot sequence. I would have expected that, if one of the destinations cannot be resolved, syslog-ng starts without it and periodically tries to resolve it later.
I did not find anything about this in the documentation (manpages of syslog-ng and syslog-ng.conf) or in the FAQ, the only thing I found was a bug in bugzilla (https://bugzilla.balabit.com/show_bug.cgi?id=63), which has been filed in 11/2009 and reports that --syntax-only does not catch unresolved _sources_ although this is considered a critical error and prevents syslog-ng from starting. I would assume that this is the same for unresolved destinations.
Any comments on this? I know that ntpd tries to resolve configured servers in a separate thread which retries resolving them every once in a while and starts using such a host as soon as it could be resolved.
Well, it'd certainly make sense to start syslog-ng even in this case, and try to connect the hosts every once in a while, just like it happened with an unreachable host. Hmm.. looking at the 3.3 code, it might be very easy to do actually, even though this part of syslog-ng has seen some changes recently. Here's a patch to do it: https://github.com/bazsi/syslog-ng-3.3/commit/e3637d7e2dc6954ebbbc7330e725d8... Since 3.3 is already declared stable, I wouldn't want to add this there, but I'm picking this patch to 3.4. I'd really appreciate if you could apply real world testing on this. -- Bazsi