[Top][All Lists]

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

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

From: Ludovic Courtès
Subject: [bug#30464] shepherd logging; console-agetty-service
Date: Sat, 17 Feb 2018 17:20:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)


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

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


> 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: <>.  Well, one thing at a time.

Thanks for the great ideas!


reply via email to

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