[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30939: shepherd: detailed output should be placed into well-known lo
bug#30939: shepherd: detailed output should be placed into well-known location and not tty
Mon, 26 Mar 2018 15:10:36 +0000
Ludovic Courtès transcribed 790 bytes:
> Hi ng0,
> ng0 <address@hidden> 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?
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
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
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
and services which are failing log into this file (or a set of files in
in files like $daemonname.fail.log).
Given the absence of the kitchensink of tools in systemd, you got used to
"status" and immediate "HELLO! This is why I failed: (5 lines)". With shepherd,
even grep for the failures in locations newcomers to the system would assume
/var/log/shepherd.log (it is the daemon control application)).
Long store short, greping for failures to fix daemon configurations and not
look at tty 1 (which can be noisy depending on what you run, I have some
spammers) would be good.
And not sacrifice the simplicity of Shepherd :)