On 03/18/2011 01:53 PM, Kay Sievers wrote:
On Fri, Mar 18, 2011 at 08:19, Rainer Gerhards<rgerha...@hq.adiscon.com> wrote:
-----Original Message-----
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Thursday, March 17, 2011 10:38 PM
To: Rainer Gerhards
Cc: Michael Biebl; Andrey Borzenkov; systemd-
de...@lists.freedesktop.org
Subject: Re: [systemd-devel] systemd-logger and external syslog daemon
On Thu, 17.03.11 08:38, Rainer Gerhards (rgerha...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
