Hi, My attention has been drawn to this Debian bugreport and after reading through it I would say that it is not really a syslog-ng issue, but rather a problem in the perl libraries that implement the syslog() call. You can find my reasoning below.
The reference to RFC3164 is not valid as that documents the on-wire protocol of syslog and not the protocol between the applications->syslog daemon (some platforms like HP-UX or Solaris for example do not use sockets for this purpose at all) On the other hand it is true that the protocol between the applications and syslog-ng resembles RFC3164 and it should use that format when possible. However RFC3164 documents a datagram based transport mechanism only while the local transport between the apps and syslog-ng can use either a datagram transport (unix-dgram) or stream transport (unix-stream). Both of these transports are supported by the libc implementation of syslog, and traditionally the latter was used on Linux systems until about 4-5 years ago. Syslog-ng supports both of these mechanisms and I personally prefer unix-stream, as in that case no messages can be lost in the local socket buffers. The datagram based transports imply the end of a message at the message barrier, therefore the addition of an NL or NUL character is redundant, this is however not true for stream transports, where two messages can be concatenated by the kernel, in which case the receiving application has to split the message based on some criteria. In the current situation, perl became incompatible with stream transport (which, again, is supported by libc), if this is the intention then the default transport of syslog-ng should be changed to unix-dgram() and it will work. In my opinion however the better solution is to readd the line terminations this way the administrator is free to choose her own syslog transport mechanism. But please note that regardless of Debian, many people on many different Linux distributions use the preferred unix-stream() source which will cause problems if perl would accept this change upstream. -- Bazsi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
