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

[Rainer Gerhards]

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Thursday, March 17, 2011 12:31 AM
> To: Michael Biebl
> Cc: Andrey Borzenkov; systemd-devel at lists.freedesktop.org; Rainer
> Gerhards
> Subject: Re: [systemd-devel] systemd-logger and external syslog daemon
> 
> On Wed, 16.03.11 07:18, Michael Biebl (mbiebl at gmail.com) wrote:
> 
> >
> > 2011/3/16 Lennart Poettering <lennart at poettering.net>:
> > > On Sat, 12.03.11 16:31, Andrey Borzenkov (arvidjaar at mail.ru) wrote:
> > >
> >
> > >>
> > >> Attached patch preserves full syslog facility marker and simply
> emits
> > >> it back. So userspace is free to feed any facility it deems
> > >> appropriate, not only LOG_USER.
> > >
> > > This is a good approach. Kay has independently prepped a patch for
> this
> > > now and it is already on its way into the kernel. It is hence very
> > > likely that pretty soon there's no reason anymore to strip the
> facility
> > > from the log messages before echoing them into /proc/kmsg.
> > >
> > > As soon as that patch is in the standard kernel I'll fix systemd to
> no
> > > longer strip the facility. Kay will do the same for udev. And
> Harald
> > > hopefully for Dracut too. And then all messages should contain the
> same
> > > amount of information regardless which way the took to the syslog
> > > daemon: directly via the /dev/log socket, or indirectly via the
> kmsg queue.
> >
> > What happens if you run udev/dracut/systemd on a kernel without this
> patch?
> 
> 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...).

Rainer