> -----Original Message----- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: Thursday, March 17, 2011 12:31 AM > To: Michael Biebl > Cc: Andrey Borzenkov; systemd-devel@lists.freedesktop.org; Rainer > Gerhards > Subject: Re: [systemd-devel] systemd-logger and external syslog daemon > > On Wed, 16.03.11 07:18, Michael Biebl (mbi...@gmail.com) wrote: > > > > > 2011/3/16 Lennart Poettering <lenn...@poettering.net>: > > > On Sat, 12.03.11 16:31, Andrey Borzenkov (arvidj...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel