Long Syslog messages getting dropped

[mehetmet]

Hello,

I am running Debian Squeeze 6.0.5.

Currently The Debian server is set up as a central syslog server receiving syslog messages from other Linux (fedora, debian, RHEL, CentOS, etc.) and from some Windows Servers.

The syslog messages from the Windows Servers are being sent via Snare.

We have recently noticed that the longer messages from the Windows Events are not being received in syslog. Any events that seem to be a certain length are just dropped and never reported.

If I configure Snare to send these messages to our CentOS 5.1 server, the messages are received, but they are cut off at a certain length (but contains the vital info). I can just have my central syslog server be the CentOS server, but this isn't ideal, as i have many servers already pointing to the Debian one.

Is there anything I can do on the Debian syslog server to ensure that these messages are received, or even cut off like the ones in CentOS?

[cnamejj]

I haven't had to mess with syslog in a long time, meaning I haven't setup anything but local syslog, but this article suggests there's a hard limit coded into "syslogd".

BSDpants: Truncated syslog messages

But since their solution is to edit the source and recompile, I'd suggest looking into using "syslog-ng" instead. If you're going to mess with your server you might as well install a more flexible syslog server. And if your Debian system is already running syslog-ng, then other articles say that the maximum message size is just a configuration option. So no source code twiddling and recompiling will be necessary.

[Irithori]

Afaik, this issue is independend of the syslog server implementation.
512bytes is hardcoded because each line is sent via ONE udp packet.
See RFC791

All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

We had a similar problem and recompiled rsyslog with 1024bytes as this should still fit in one packet.
I wouldnt go beyond, unless you have jumbo frames configured working with all network devices, who need to deal with syslog in that network segment.

[cnamejj]

Afaik, this issue is independend of the syslog server implementation.
512bytes is hardcoded because each line is sent via ONE udp packet.
See RFC791


We had a similar problem and recompiled rsyslog with 1024bytes as this should still fit in one packet.
I wouldnt go beyond, unless you have jumbo frames configured working with all network devices, who need to deal with syslog in that network segment.

That, meaning UDP limitations, was my gut instinct too. I know you can use TCP instead of UDP with syslog-ng so you can avoid the whole issue by switching.

[Irithori]

TCP (plus payload config, as syslog still assumes 512bytes) is a way, if you can live with the overhead.
Todays machines and networks can, unless we are talking thousands of machines and high logging frequency.

But this needs to be configured on both client and server.
No problem with s/th like syslog-ng and rsyslog,
but I am not sure about snare.
I believe it has its own, syslog incompatible protocol over tcp, which offers authentication, encryption, etc

[mehetmet]

Thanks for all the help, I will try the above suggestions!