Hi Ludovic, Ludovic Courtès transcribed 790 bytes: > Hi ng0, > > ng0 <[email protected]> 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 :)
