17

Most Unix programmers would be used to the interface defined by syslog.h, and many implementations (such as glibc) have no real limit on the size of the syslog message being sent to it, but there is usually a limit on the application listening to /dev/log.

I'm wondering if anyone knows a way to find the maximum message size for the syslog? Or some good documentation of what the limit actually (or usually) is?

Edit:

So far I've found these RFCs on the topic:

Petriborg
  • 2,940
  • 3
  • 28
  • 49

3 Answers3

10

Keep in mind syslog is a protocol, which means it sets minimums and makes recommendations. I can't find a source to this, but I believe the minimum length that should be supported is 1k, with 64k being recommended.

Each implementation is free to do what they want, i.e. if you wanted a 16MB maximum and were writing a syslog server, you're free to do that. I'm not sure why you would, but you could.

As far as I know, there is no standard programatic way of ascertaining this, so keeping messages at just under 1k would be ideal for portability.

Update

User MuMind indicated in comments that rsyslog truncated at 2097 characters, including log type / time stamp. As it is a widely used implementation of the protocol, this reinforces that length should be kept to between 1k - 1.5k for maximum portability.

Honestly, the only reason to exceed that would be to log additional debug / crash output; it's much better to put that somewhere in /var/log instead, and just indicate that you did so when talking to syslog (granted, there are scenarios when you couldn't, but plenty of libraries have 'best effort' logging built in to deal with that).

Community
  • 1
  • 1
Tim Post
  • 33,371
  • 15
  • 110
  • 174
  • Yeah exactly - is there anything out there that documents this 1k, 64k, 16mb thing? Even if I can't figure it out in a programatic way, it would be good to document where this random constant is coming from in the code. – Petriborg Jul 22 '10 at 18:02
  • Of course I should have realized there is an RFC(s) about syslog - http://www.faqs.org/rfcs/rfc5426.html - http://www.faqs.org/rfcs/rfc3164.html So I guess that will do – Petriborg Jul 22 '10 at 18:04
  • 1
    @Petriborg - Its implementation specific, but no standard means exist to ascertain the limit. You could (perhaps) start writing in multiples of 1k chunks until syslog() fails at configure time to figure it out but that's just icky, your logging routines still have to break it down into chunks, which is even more icky. What you can't send to syslog .. just send to a logfile and reference it in syslog? I can't find a consensus on if a message that exceeds the limit will be truncated or just rejected, either. – Tim Post Jul 22 '10 at 18:14
  • 2
    On my system with rsyslog, I saw messages truncated (at 2097 characters, including timestamp) in /var/log/auth.log. No idea if that's guaranteed or other implementations work the same. – Mu Mind May 22 '14 at 04:52
  • @MuMind Interesting, and that's a very widely used implementation of the protocol, so keeping message length between 1k / 1.5k _with_ timestamp and log type seems like a good defensive approach. Honestly, I don't see why anyone would need more than 1k, if you're doing debug data dumps you should just be doing that in /var/log anyway, and indicating you did so in syslog. I'm going to update my answer. – Tim Post May 22 '14 at 08:38
  • 1
    BTW, ignoring the leading timestamp and hostname it was 2044 characters. – Mu Mind May 22 '14 at 15:32
8

"Old" Syslog

For "old" (RFC 3164) syslog the maximum length of a syslog datagram's payload (including the encoded priority and timestamp) is 1024 octets, as per section 4.1 and there is no minimum length, though empty syslog packets should be dropped. Further, longer datagrams should never be forwarded as per section 6.1. (Relays must truncate packets if they add timestamp information that would increases the length; section 4.3.2.)

This is really old and nobody really follows this any more, but it's something to keep in mind if you're working with very old systems.

"Modern" Syslog

Modern systems follow (more or less) RFC 5424 where in section 6.1 it sets the minimum size that everybody must be able to handle to 480 octets, suggests that everybody be able to handle at least 2048 octets, and has no maximum.

A very frequently used transport is UDP, defined in RFC 5426, where section 3.2 goes into detail about the message size. The maximum permissible is as big as you can fit in a datagram that you can get through the network (which will be a bit under 64k, depending). However, the minimum required is 480 octets for IPv4, and preferably systems should accept at least 2048 octets. There's a bit of further stuff about MTUs and the like, though, so in general, if you're not sure about the systems you're dealing with, you probably want to restrict the size to be under the lowest MTU of your path when all headers and the like are included; about 1300 octets would be a good guess if you're not sure.

That's just for UDP, though; over a TLS link receivers must be able to process at least 2048 octet messages and preferably 8192 octets (RFC 5425 section 4.3.1. But of course you need to be careful with this because if the message happens to be forwarded over a UDP transport later, the UDP lengths apply.

Rsyslog

Rsyslog (sorry, Ranier, but the "proper" all-upper-case form is distracting) is probably the most popular syslog daemon these days. (Even systems that use systemd/journald still use rsyslogd for network reception and transmission of log messages in syslog format.)

Rsyslog added the ability to set the maximum message size used in many areas of the program (the maxMessageSize configuration parameter) in version 6.3.4 in 2011 and at this time the default value was set to 8096 octets, where it has remained since.

Community
  • 1
  • 1
cjs
  • 25,752
  • 9
  • 89
  • 101
4

Since syslog is a protocol to be used over UDP, in this case the limit is the UDP datagram size minus a few bytes for the headers which is around 65k. The /dev/log unix domain socket can be either a datagram or stream socket (SOCK_STREAM or SOCK_DGRAM), in the former case the 64k limit does not apply but it is best to consider the UDP datagram size as the limit if you are not the author of the program reading the messages.

b0ti
  • 2,319
  • 1
  • 18
  • 18