[syslog-ng] Unpredictable log output when message has manynewlines

[Geller, Sandor (IT)]

Hi,

> I use the default settings, ie unix-stream("/dev/log") defined in the
> s_all source.  I ran the tests with unix-dgram instead, and it fixes

There are no default settings. You're up to make your own config file
as syslog-ng doesn't install any kind of default configuration AFAIK.

> the problem.  Maybe the documentation at
> http://www.cs.utah.edu/~clake/docs/syslog-ng-2.0/#id2524704 may
> require some update?  What about making dgram the default?

There is no default as I pointed out above. If you ever want to build
a reliable syslog infrastructure you have to omit UDP and unix-dgram.

BTW you can send random data to syslog but before doing so sometimes
it is handy to read at least the RFC about syslog. Some people think
syslog has been designed to be a data transport. No, it hasn't. See
RFC3164 Section 4.1.3 for reference. Your data definitely violates the
syslog protocol so I won't expect predictable/ correct behaviour.

I was able to reproduce your problem and the strace output showed that
write() calls send whole lines. The problem is on the receiver's side.
When syslog-ng is under strace the problem occurs more frequently.

My assumption is that the stress testing program fills up the input
buffer and syslog-ng reads to the first '\n'. As the test string does
contain linefeed characters syslog-ng assumes that it is the end of
the message and writes the partial string to the destination. If you
haven't used the default facility/priority settings in your test
script you would have notice the difference as syslog-ng applies
user/notice to the logs which don't have fac/pri set.

For UDP/ dgram there is no such problem as syslog-ng handles the whole
packet in one iteration. When the dgram queue is full the logs would
be dropped by the OS without any kind of notification. So using
unix-dgram you won't see partial messages, but this doesn't mean that
there are no problems.

Regards,

Sandor
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.