GNU bug report logs - #30939
shepherd: detailed output should be placed into well-known location and not tty

Previous Next

Full log

View this message in rfc822 format

From: ng0 <ng0 <at> n0.is>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 30939 <at> debbugs.gnu.org, ng0 <ng0 <at> n0.is>
Subject: bug#30939: shepherd: detailed output should be placed into well-known location and not tty
Date: Mon, 26 Mar 2018 15:10:36 +0000

Hi Ludovic,

Ludovic Courtès transcribed 790 bytes:
> Hi ng0,
> 
> ng0 <ng0 <at> n0.is> skribis:
> 
> > Problem, not just when a service is misbehaving after successful system reconfigure:
> >
> > $ sudo herd start smtpd
> > Password: 
> > Service smtpd could not be started.
> > herd: failed to start service smtpd
> >
> >
> >
> > This is on virtual terminal in X11, as well as in /var/log/messages,
> > /var/log/shepherd.log, etc.
> > This is not enough. If I wanted more info, I'd expect that
> > sudo herd status smtpd would give it (which it does not), so the only
> > reliable source of information so far is tty 1. Can we fix that in
> > one of the next shepherd releases? Or is this something we have to
> > fix in Guix?
> 
> So you’re saying that you’d like shepherd to show more info as to why
> the service could not be started, right?
> 
> Thanks,
> Ludo’.

Must have been late and too many failed attempts at what I'm trying to do.
Yes. So I can't make any daemons I run out there fail, but for the
current case I have in Guix for this:

Sometimes I succeed building a system generation with an OpenSMTPD config-file
which has syntax error that aren't picked up at configure time. When I reboot,
not being aware of this, I have to switch to tty to read the reasons why it
crashed.
Because this is a desktop system, I have to start the service again to see
the error output directly from the daemon.

I think I know why this happens (that the output goes to tty), but nevertheless
it would be good if shepherd were more capable than beint captain obvious:
Start: "Oh, you see it is started". Crashed: "Oh, no has your daemon crashed?",
like it is now.
....
Okay, I just looked at some other daemon controls I run, and maybe it's good that
shepherd is limited in its output. It does this one job. What I'd like to have
as a sysadmin is the ability to tail something like say /var/log/shepherd.fail.log
and services which are failing log into this file (or a set of files in /var/log/shepherd/
in files like $daemonname.fail.log).
Given the absence of the kitchensink of tools in systemd, you got used to something like
"status" and immediate "HELLO! This is why I failed: (5 lines)". With shepherd, you can't
even grep for the failures in locations newcomers to the system would assume (like:
/var/log/shepherd.log (it is the daemon control application)).

Long store short, greping for failures to fix daemon configurations and not having to
look at tty 1 (which can be noisy depending on what you run, I have some notorious tty
spammers) would be good.
And not sacrifice the simplicity of Shepherd :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.