On Fri, 11.03.11 08:45, Michael Biebl ([email protected]) wrote: > > 2011/3/11 Rainer Gerhards <[email protected]>: > > > > 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
