What I would like to have is "s6-rc -d change foo" sending SIGTERM and then
SIGKILL if the service is not down after x seconds. Currently If a daemon hangs
it has annoying side effects. If I don't put a timeout on the s6-rc command
the state machine is blocked, and I cannot shut down the system anymore. If I do
put a timeout, s6-rc considers the service is down while it is not. It is then 
to stop or restart it. When timeout occurs, maybe s6-rc should send SIGKILL to
make sure the service is down ?

From: supervision@list.skarnet.org <supervision@list.skarnet.org> on behalf of 
Laurent Bercot <ska-supervis...@skarnet.org>
Sent: Tuesday, May 2, 2017 10:51:19 AM
To: supervision@list.skarnet.org
Subject: Re: Customise shutdown signal at the s6-rc level?

>[1] <link to an incomplete post>
  Damn ezmlm-cgi bug, this time it triggered without an accented
character. Sorry about that :(
  Here's the URL to the full message:

  About customizing shutdown signals in s6-rc: how do you suggest it
be done? There are two ways I can see it work:
  1. by including a call to the "trap" binary in the generated run
  2. by including the "what signal should I send" information into the
generated service database and making "s6-rc -d change foo" use that

  Solution 1 means adding magic that changes the process tree, and I'm
very reluctant to do that. s6-rc-compile already performs magic with
run scripts (to move around fds for pipelining and notification), but it
doesn't change the final process tree: the long-lived process *is* the
user's run script. Adding a call to trap would break that expectation,
and I don't think it's worth it: users who need it can perform the
trapping in their run script themselves. (It's trivial to do in shell.)

  Solution 2 means changing the s6-rc database ABI by adding a field
(which is doable at the cost of a major version bump and recompilation
of every user database), but more importantly, it means that s6-svc -d
is not automatically valid anymore, and more investigation (looking into
the s6-rc-database to find the correct signal...) is necessary for a
user to know the right way to temporarily stop a service. It's an
additional know-how burden I don't want to put on users, most of whom
are already having a hard enough time with s6 as is.

  Neither of those solutions is appealing to me. Currently, if someone
needs to use a different shutdown signal, I would recommend them to
manually perform a trap in their run script, be it with s6 or with

  If I were to work on a more official, better integrated solution, I
do it at the s6-supervise level. I would not implement custom control
scripts, for the reasons indicated in the above link, but it would
probably be possible to implement a safer solution, such as reading a
containing the name of the signal to send when s6-svc -d is called.

  Is there a real, important demand for this? I'd rather not do it and
daemons that don't use SIGTERM to shutdown instead...


Reply via email to