guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#30498] [WIP v2 shepherd] shepherd: If /dev/kmsg is writable, use it


From: Ludovic Courtès
Subject: [bug#30498] [WIP v2 shepherd] shepherd: If /dev/kmsg is writable, use it for logging.
Date: Wed, 07 Mar 2018 13:46:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hello,

Danny Milosavljevic <address@hidden> skribis:

>> There’s one thing we need to improve though: syslogd reads /proc/kmsg
>> and prefixes everything that comes from there with “vmunix” (as if it
>> came from the kernel).  
>
> Also, apparently syslogd uses the timestamp of "when it read the messages
> out of /dev/kmsg" as syslog entry timestamp *although* /dev/kmsg contains its
> own timestamps (as offsets-from-bootup).  Hrmmm...

Yeah, we could teach Inetutils’s syslogd to interpret those timestamps,
although that’s a Linux-specific thing so care must be taken.

> According to the Linux kernel documentation the /dev/kmsg ring buffer is
> specifically allowed to be used by user processes (although they must not
> impersonate the kernel - if they try, the specified priority is ignored),
> so we're in the clear there.

Yeah but still.  From syslogd’s viewpoint, you can only assume that
these messages originate in the kernel.

> Later on, we should use /dev/log and fall back to /dev/kmsg and
> then again use /dev/log as it gets available etc.  I'm not sure
> how to do the synchronisation (from shepherd's point of view,
> syslogd asynchronously reads from /dev/kmsg and puts the messages
> into its output files - so if we write to /dev/kmsg, then to
> /dev/log, then to /dev/kmsg, then to /dev/log, is the message order
> guaranteed?)

syslogd will read a batch of messages from /dev/kmsg when it starts, so
the order is not really honored in this case.  I think that’s OK though,
because we don’t expect users to keep stopping/starting syslogd.   :-)

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]