Hi, I think it's rather an issue on the reader side not on the sender. With stream sources using unstructured data (like the plain tcp source driver) it is impossible to differentiate between an embedded newline and the end of a message which is also a newline. A read-ahead-like heuristics could work around this to some extent but it won't be a proper solution (due to how TCP works there is no guarantee that whole messages will be transmitted in a packet and there will be data in the socket to read to see whether the next line looks like a syslog header) so I'd recommend using the syslog() driver. Probably there has been something implemented already, I'm not sure. Regards, Sandor On Thu, Apr 18, 2013 at 2:59 PM, Hannes De Bondt <hannes@netlog.com> wrote:

Best,

Is it possible there is a different behaviour in the tcp destination.

We see a different behaviour. We had a working setup with 2.0.x and while upgrading to 3.3.x we noticed the newlines in our messages are seen as EOM, causing a part of our logging to be lost.

Is there a quick workaround for this?

Kind regards

Hannes De Bondt

______________________________________________________________________________ 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