[systemd-devel] systemd-logger and external syslog daemon
arvidjaar at mail.ru
Fri Mar 11 08:41:41 PST 2011
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
>> 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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3799 bytes
Desc: not available
More information about the systemd-devel