Hi,

On Mon, 05 Mar 2018 17:51:44 +0100
ludo@gnu.org (Ludovic Courtès) wrote:
> I tested it in a GuixSD VM and it works as advertised!  \o/

Yay!

> 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...

>That’s inconvenient because it makes it
> impossible to have syslogd rules to filter shepherd messages.

I've added a shepherd "prefix" in the shepherd messages, so it should
end up as "vmunix: shepherd[1]: ..." (or so).

The somewhat heavyhanded way to fix it would be to replace

  strcpy (line, "vmunix: ");

by

  strcpy (line, "");

in inetutils-1.9.4/src/syslogd.c .  Or use another syslogd :)

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.

> So I think we need to do instead use a ‘syslog’-style interface and,
> similar to what ‘syslog’ does in glibc, write to /dev/log unless it’s
> unavailable, in which case we fall back to /dev/kmsg.

Yes, in the long run, we should do that.  I think for this shepherd
release it would be fine to use only /dev/kmsg - it's still an
improvement - and the risk that we introduced a new bug by this is
basically nonexistent.

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?)

>I’ll see if I can give it a try.

Thanks :)