What I would like to have is "s6-rc -d change foo" sending SIGTERM and
SIGKILL if the service is not down after x seconds. Currently If a
it has annoying side effects. If I don't put a timeout on the s6-rc
the state machine is blocked, and I cannot shut down the system
Yes, I know that problem. The real solution, of course, is to fix
daemons so they don't hang after SIGTERM...
I've often thought about changing the s6-svc -d semantics to send a
SIGKILL after a timeout, just like s6-supervise already does with the
finish script. I've never pulled the trigger because it requires
changing the s6-supervise automaton, but if it's necessary to prevent
hangups and unrecoverable states in the state machine, I'll have to do
it at some point.
When timeout occurs, maybe s6-rc should send SIGKILL to
make sure the service is down ?
No, when a timeout occurs, s6-rc just exits and the state is not
supposed to have changed (and if it has, the next s6-rc invocation
picks it up).
The "daemon doesn't die on SIGTERM" issue should not be handled at the
s6-rc level anyway: it's a process issue, not a service issue, so it
should be handled by s6. Implementing a way for s6 to send a SIGTERM,
then a SIGKILL if the daemon still hasn't died after a timeout, is the
correct answer. (Please don't expect it to be done tomorrow though.)