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.
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
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).
I think that real solutions are numbers 1 and 3, with 3 probably having
the best arguments. However, I have to admit I do not like this option
very much at all.
A fourth option would be to add two new property replacer argument "add
<SP> at end if none is already there" and "drop first <SP> if there is
one". I could then modify the default templates to use the first one
with Tag and the later with MSG (instead of the regular ones). That
would be a good fix, probably my favorite, BUT it would also cause
format change, now in other messages. Plus, it is a little bit to code
and I prefer to do as few code changes to a stable as possible.
This issue has unfortunately been lurking ever since the beginning of
rsyslog (as it is rooted in rfc 3164) and I should probably have it
addressed earlier. But as you see: it is ugly... ;)
So question now: what do the list members think?
Feedback is highly appreciated.
Thanks,
Rainer
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.
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
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).
I think that real solutions are numbers 1 and 3, with 3 probably having
the best arguments. However, I have to admit I do not like this option
very much at all.
A fourth option would be to add two new property replacer argument "add
<SP> at end if none is already there" and "drop first <SP> if there is
one". I could then modify the default templates to use the first one
with Tag and the later with MSG (instead of the regular ones). That
would be a good fix, probably my favorite, BUT it would also cause
format change, now in other messages. Plus, it is a little bit to code
and I prefer to do as few code changes to a stable as possible.
This issue has unfortunately been lurking ever since the beginning of
rsyslog (as it is rooted in rfc 3164) and I should probably have it
addressed earlier. But as you see: it is ugly... ;)
So question now: what do the list members think?
Feedback is highly appreciated.
Thanks,
Rainer