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

Andrey Borzenkov 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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: printk-user-space.patch
Type: text/x-patch
Size: 3799 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110311/6c450c46/attachment-0001.bin>


More information about the systemd-devel mailing list