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

[Ludovic Courtès]

Hi,

Danny Milosavljevic <address@hidden> skribis:

> On Thu, 15 Feb 2018 16:47:54 +0100
> address@hidden (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.

That’s already done.

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

Yes, I like it too.  OTOH, there’s a chicken-and-egg problem here:
shepherd ends up implementing its own logging facility, and we have
situations like the one you mentioned earlier in this thread.

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

Indeed, that’s something we can easily do already, and it would address
a major annoyance.  :-)  Actually, could it use syslog(3), which writes
to /dev/log?

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

Yes.  Though again capturing service stdout/stderr is kinda redundant
with what syslogd does.  What I like in journald is the fact that it
unifies all logging facilities, and also connects them to service
management.

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

Right, so we’d need shepherd to filter these and pass them through
syslog(3), which ensures correct message formatting.  That’s what
<https://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-kmsg.c>
does apparently (thanks for the link!).

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

Sure!

> 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 (!).

Sounds like a great source of inspiration then.  :-)

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

That brings us to the topic of a general service customization
mechanism: <https://bugs.gnu.org/27155>.  Well, one thing at a time.
:-)

Thanks for the great ideas!

Ludo’.