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

[Lennart Poettering]

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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.