when defining a service type that extends shepherd-root-service-type and
the 'start' function of the shepherd-service definition contains an
error, the error is silently ignored. No log output is generated at all.
For example (full system definition is attached):
(define (errtest-shepherd-service c)
(documentation "Errtest")
(requirement '(file-systems))
(modules `((shepherd support) (ice-9 match) ,@%default-modules))
(local-output "errtest start")
this-is-an-unbound-variable
(local-output "errtest end")
The log message "errtest start" appears in /var/log/messages, as
expected. The next line contains an error, and aborts execution of the
The error only becomes apparent when manually doing a "herd restart
errtest", which shows an error message (but without any error location
or stack trace). But the error (regarding the unbound variable) is not
logged, and there is no indication in the log that the service couldn't
Furthermore the "herd status" of a service that encountered an error in
the start function is very misleading:
root@errtest ~# herd status errtest
It shows "Will be respawned", which is wrong.
I'd be happy to work on a patch, but it seems like there is some design
discussion necessary, in particular how the "Will be respawned" should
be handled. Services have a "respawn?" flag, but of course respawning
can only work if the start function executed successfully (and only the
service process itself failed) in the first place.
I generally feel like the state machine for services needs some work.
In particular, it would be useful to distinguish between "failed" and
"completed" services instead of conflating both states into "stopped".
Or maybe have some more general mechanism for storing state about the
service, instead of just the slot that usually contains the PID?