[systemd-devel] systemd-logger and external syslog daemon

[Rainer Gerhards]

On 03/18/2011 01:53 PM, Kay Sievers wrote:
> On Fri, Mar 18, 2011 at 08:19, Rainer Gerhards<rgerhards at hq.adiscon.com>  wrote:
>>> -----Original Message-----
>>> From: Lennart Poettering [mailto:lennart at poettering.net]
>>> Sent: Thursday, March 17, 2011 10:38 PM
>>> To: Rainer Gerhards
>>> Cc: Michael Biebl; Andrey Borzenkov; systemd-
>>> devel at lists.freedesktop.org
>>> Subject: Re: [systemd-devel] systemd-logger and external syslog daemon
>>>
>>> On Thu, 17.03.11 08:38, Rainer Gerhards (rgerhards at hq.adiscon.com)
>>> wrote:
>>>
>>>>> You mean a new udev/dracut/systemd on an old kernel? The messages
>>> they
>>>>> print would look a bit weird if they are used together with log msg
>>>>> timestamping the way the kernel does it, since the kernel doesn't
>>>>> recognize the prefix. (See Kay's post about this). But besides
>>> these
>>>>> cosmetic issues nothing should really go wrong.
>>>>>
>>>>> (I wonder if we can find a nice way to detect whether the kernel is
>>> new
>>>>> enough for this, so that we could strip the facility automatically
>>> for
>>>>> older ones. Explcitily checking for kernel versions at runtime is
>>> evil
>>>>> though... I can't think of a good way though...)
>>>>
>>>> Wouldn't it work to check if there is a "<PRI>" right at the start of
>>> the
>>>> message? I think that it is actual user data would be extremely
>>> improbable,
>>>> so this should be a good enough indication. That way, we could pull
>>> the PRI
>>>> even without the kernel patch (but, granted, it is kind of an
>>> interface
>>>> change...).
>>>
>>> Hmm?
>>>
>>> The question is how we can detect whether it is safe to write messages
>>> to kmsg with PRI values with more than 3 bits. 2.6.39 and above will be
>>> able
>>> to handle that properly, even if you enable per-line printk kernel
>>> timestamping. On 2.6.38 only 3-bit-PRI values will look good if you use
>>> printk kernel timestamping.
>>
>> Probably I misunderstood the answer to "what happens on a kernel without that
>> patch if a full PRI is written?". I understood the answer was "the PRI is
>> moved into the message".
>>
>> So "<123>msg"
>> would actually become
>> "<1>  [TS]<123>Msg"
>>
>>  From your answer I deduce this understanding is incorrect. So what will then
>> happen on kernels without that patch if printk is provided a message
>> "<123>MSg"?
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d90c8d9cde929cbc575098e825d7c29d9f45054

That's what I understood and what I based my proposal on. In that case, 
rsyslog can simply check if there is an additional priority. I just did 
some quick PoC:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=bb67fd7fbf99ce0ec01b347fad5d1d9d101bfa5d

Looks like it works pretty well. So systemd could simply always write 
the full priority and the syslogd would just need to check for the extra 
header. If the syslogd is not capable of doing that, the message will 
look a bit strange. But in that case, the priority is wrong in any case, 
and so chances it will be properly routed are slim...

Rainer