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

Rainer Gerhards rgerhards at hq.adiscon.com
Fri Mar 11 08:47:08 PST 2011


> -----Original Message-----
> From: Andrey Borzenkov [mailto:arvidjaar at mail.ru]
> Sent: Friday, March 11, 2011 5:42 PM
> To: Lennart Poettering
> Cc: Michael Biebl; systemd-devel at lists.freedesktop.org; Rainer Gerhards
> Subject: Re: [systemd-devel] systemd-logger and external syslog daemon
> 
> On Fri, Mar 11, 2011 at 7:11 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Fri, 11.03.11 08:45, Michael Biebl (mbiebl at gmail.com) wrote:
> >
> >>
> >> 2011/3/11 Rainer Gerhards <rgerhards at hq.adiscon.com>:
> >> >
> >> > So isn't that already a solution?
> >> >
> >>
> >> The problem with PRINTK_TIME afaics is that it needs to be turned on
> >> explicitly whereas I'd expect SO_TIMESTAMP will be available always
> >> (if the kernel is recent enough)?
> >
> > PRINTK_TIME applies to /proc/kmsg data. SO_TIMESTAMP applies to
> > /dev/log sockets.
> >
> >> In any case you'd need to interpret that data on the rsyslog side, to
> >> compute a correct time stamp and then (optionally) strip off the [
> >> 5913.491848] markers.
> >
> > Yupp, that's what I'd like to see.
> >
> > But there's actually something else I'd like to see, as well:
> >
> > Parse the <x> priority field read from /proc/kmsg like it is normally
> > done for /dev/log messages.
> >
> > i.e. traditionally, since only the kernel wrote to dmesg all lines
> > where prefixed with prios from the range 0..7 only. And some tools can
> > just parse that: a prefix of "<" plus one number from 0..7 plus ">".
> > It would be cool to beef that up and parse the full 8bit priority
> > field there too, i.e. not just the 3 bit for the priority, but also
> > the 5 bit for the facility. Since facility=0 refers to kernel messages
> > the kernel messages would be identified as facility=kernel, but in
> > case user code logs something there it can pass the correct facility
> > and the userspace syslog daemon should then not override that facility
> > with kernel anymore.
> >
> > The result of this all put together would be that userspace can log
> > via /dev/kmsg or via /dev/log and not metadata would be lost anymore.
> > Not the prio, not the facility, and not the timestamp.
> >
> 
> Well ... the problem really is that format is supposed to be single
printable
> character, which does not really support bit operations and such. What
about
> attached (completely untested) path - which adds <u> marker to anything
> written into /dev/kmsg?

If it is just a single character, I need to obtain the real facility/severity
somewhere. Could that be written to some fixed place, e.g. immediately after
"<u>"? That way, I'd know exactly what is going on and can remove the extra
formatting on the syslogd side.

Note that in the future we may have signature in syslog messages (RFC was
recently published). That means we must ensure that the message text is not
altered while it is being shuffled back and forth -- that would invalidate
the signatures and potentially create *big* problems in compliance.

Rainer


More information about the systemd-devel mailing list