[bug#30464] shepherd logging; console-agetty-service

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Ludo,

On Thu, 15 Feb 2018 16:47:54 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> (Which has me thinking that longer term it’d be nice to have the
> Shepherd take care of syslogd-ish activity.)

If you mean that we should make sure to log shepherd's own messages, I agree.

Integrating syslogd into shepherd, not sure.  I think external syslogd is fine.
If not, there are a lot of other logging programs to choose from.
I like modularity.

shepherd could write its messages to the kernel log ringbuffer in /dev/kmsg [3].
That sounds dirty, but it would synchronize messages oh-so-nicely and would
not immediately require syslogd.  It would also make sure that syslogd
eventually picks shepherd's messages up (right now they are somewhere on the
first terminal - if you are lucky and they didn't scroll off).

I'm not sure whether then they would be printed to /dev/console as well then -
probably.

We'd need a guile soft-port, but it's not like I haven't done that before.

User-shepherd shouldn't do it though (and can't because it doesn't have
permission to write to /dev/kmsg).

Please stop me and tell me why it's a bad idea :)

Also a way of capturing stderr and stdout (and maybe even /dev/log) of services
would be nice.

If you thought that the above was bad, you ain't seen nothing yet :->

We could also instead open /dev/klog and dup2 its fd to 1 and 2.
That way, shepherd messages and all stray messages by any process shepherd
started will end up in the kernel log.  (problem: there are some reserved
patterns that have special meaning - and we don't control what the services
do as well as we do what just shepherd does)

Also, I know one is supposed to write UNIX services as daemons, but that's
not really composable and kinda complicated to debug for no good reason.
I'd prefer if shepherd also keeps a way to run regular programs as services,
making sure that they are session leader, their output is logged, they are
kept alive and monitored.

daemontools[1][2] have done all this stuff already and I like it much more
than traditional service managers.  It's much more modular, handles logging
on its own, handles error cases well, uses the file system well etc, handles
errors in the loggers (!).

> How about adding a ‘dependencies’ field to <agetty-configuration>?  It’d
> default to the empty list, and could be set to '(syslogd) in this case.
> 
> Does that sound too obscure to you, or would it be OK?

Sure, let's do that.

It's a little weird to have it for all agettys, although maybe some other users
of agetty require it anyway.

Then I wonder if all guix shepherd service configs should have such a field.

[1] https://isotope11.com/blog/manage-your-services-with-daemontools
[2] https://cr.yp.to/daemontools/faq/create.html
[3] https://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-kmsg.c
dev_kmsg_fd = open("/dev/kmsg", O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
printf "<%i>" priority identifier "[" pid "]: " message "\n"

Linux:

	/*
	 * Extract and skip the syslog prefix <[0-9]*>. Coming from userspace
	 * the decimal value represents 32bit, the lower 3 bit are the log
	 * level, the rest are the log facility.
	 *
	 * If no prefix or no userspace facility is specified, we
	 * enforce LOG_USER [which is 1], to be able to reliably distinguish
	 * kernel-generated messages from userspace-injected ones.
	 */