[syslog-ng] Bug: syslog 2.0.x circular message delivery if no DNS

Evan Rempel erempel at uvic.ca
Thu Oct 18 18:33:04 CEST 2007

Andreas Kurz wrote:
> On 10/18/07, Balazs Scheidler <bazsi at balabit.hu> wrote:
>> On Wed, 2007-10-17 at 10:42 -0700, Evan Rempel wrote:
>>> We recently has an unscheduled power outage in our data center.
>>> Our servers came back prior to our DNS being available (actually, prior
>>> to the network coming back up). All hosts running syslog-ng consumed their
>>> log filespace as fast as the disks would allow writing which took about 2 minutes.
>>> The problem we seem to have encountered is that our source section and destination
>>> definitions are;
>>> source local { unix-stream("/dev/log" max-connections(200));
>>>                 file("/proc/kmsg" log_prefix("kernel: "));
>>>                 tcp( localip( port(514) );
>>>                 internal();
>>>               };
>>> destination syslogServer1 { tcp("syslog.uvic.ca" log_fifo_size(50000) ); };
>>> It seems that if syslog.uvic.ca could not be resolved, syslog-ng took it upon itself
>>> to use as its destination and started logging to itself. Chaining of hostnames
>>> is on, which means that we could see a message path of
>>> local at myhost.uvic.ca/local at myhost.uvic.ca/local at myhost.uvic.ca/local at myhost.uvic.ca/local at myhost.uvic.ca
>>> until some maximum length was reached and the hostname field became truncated.
>>> This should be easy to repeat if you use a source like the one above, disconnect the network
>>> and start syslog-ng.
>> I was already thinking about the idea of dropping internal messages
>> generated while another internal message is being delivered to prevent
>> such loops.
> Just out of curiosity:
> What is the intention of the line 'tcp( localip( port(514) );' ?
> Which local logging messages are not processed if just using:
> source local { unix-stream("/dev/log" max-connections(200));
>                      file("/proc/kmsg" log_prefix("kernel: "));
>                     internal();
>                   };

We use multiple instances of syslog-ng on our systems to get logs from applications that can not syslog.
We moved away from having the "system syslog" tail files and read pipes and placed this functionality into
a separate syslog-ng that is started with and shutdown with the applications init scripts.

These other instances of syslog-ng have NO WAY to "syslog" files as the author has declined the suggestion of
having a "syslog" destination in syslog-ng (I know, I can write a patch :-). Anyhow, the only way to get
data back into the "system syslog" which is where the internal messages need to go, is to have some supported 
destination. We have been using a syslog port, but I think we will be moving to a pipe for security reasons.

I hope this is at least a little clear :-)

Evan Rempel

More information about the syslog-ng mailing list