GNU bug report logs -
#30464
[PATCH 0/2] Add console-agetty-service.
Previous Next
Full log
Message #29 received at 30464 <at> debbugs.gnu.org (full text, mbox):
Hi,
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> On Thu, 15 Feb 2018 16:47:54 +0100
> ludo <at> 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.
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’.
This bug report was last modified 3 years and 120 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.