[rsyslog] slight kernel log format inconsistency between 3.16.2 and 3.18.0

[Michael Biebl]

2008/7/14 Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Hi all,
>
> Michael Biebl noticed a small inconsistency in kernel log format:
>
> 3.16.x (and before):
> Jul 11 17:33:28 pluto kernel: [14177.432349] ADDRCONF(NETDEV_CHANGE):
> wlan0: link becomes ready
> Jul 11 17:53:17 pluto kernel: Kernel logging (proc) stopped.
> <upgrade auf 3.18.0>
>
> 3.18.0:
> Jul 11 17:53:17 pluto kernel:imklog 3.18.0, log source = /proc/kmsg
> started.
> Jul 11 17:55:56 pluto kernel:Kernel logging (proc) stopped.

another example:
Jul 15 13:43:42 pluto kernel:<6>[47539.265140] eth0: link down

See the <6> after the kernel: tag. It's also new.
Is this some kind of log level, set by the kernel?
I have never seen, that other syslogger (like syslog-ng, sysklogd set this).

>
> As you can see, there is a space <SP> after kernel: in the pre-3.18.0
> messages. This also brings us down to a general inconsistency:
>
> Unfortunately, RFC 3164 defines the <SP> after TAG not as a delimiter
> but as part of the CONTENT of the message. This leads to some
> inconsistency in practice. Depending on who generated the message, there
> may be a space after the TAG or not. If it is, that space must be
> submitted as part of the message itself.
>
> In versions up to 3.16.x, kernel log messages were generated by old
> code, which did not know about tag and simply generated a non-structured
> message. With 3.17.x and above, the klog code is rewritten and correctly
> fills in all properties. This leads to the "missing" space, because the
> space is neither part of the tag nor part of the message.
>
> I have now three options:
>
> 1. leave as is (without a space)
> In that case, some log parsers may run into troubles

This was a rather vague concern of mine. I don't actually know, if
other software is affected by this change.

> 2. add a <SP> at the end of the TAG
> That will probably lead to even more confusion, as matches against TAG
> would need to include that space.
>
> 3. add a <SP> in front of each kernel message
> This comes close to the previous mode, but is "a bit" clumpsy and
> hackish. It will also make all database tables etc have messages
> starting with <SP>. Similar as 2, MSG matching rules are affected (but I
> consider this less severe, as matches inside the MSG are usually driven
> by searches and not absolute positions).

Just curious: For other log messages, that are not generated by the
kernel, you have a space after the programname: tag, e.g.
Jul 15 13:43:50 pluto dhclient: DHCPACK from 192.168.2.1

Is the space after dhclient: part of the message or part of the
:programname tag?

Imho, if there is no clear definition in the RFC, how the message
should be written, it's best to stay backwards compatible.


Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?