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 impossible
to stop or restart it. When timeout occurs, maybe s6-rc should send SIGKILL to
make sure the service is down ?
Lionel
________________________________________
From: supervision_at_list.skarnet.org <supervision_at_list.skarnet.org> on behalf of Laurent Bercot <ska-supervision_at_skarnet.org>
Sent: Tuesday, May 2, 2017 10:51:19 AM
To: supervision_at_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:
https://www.mail-archive.com/supervision_at_list.skarnet.org/msg01427.html
About customizing shutdown signals in s6-rc: how do you suggest it
should
be done? There are two ways I can see it work:
1. by including a call to the "trap" binary in the generated run
script.
2. by including the "what signal should I send" information into the
generated service database and making "s6-rc -d change foo" use that
information.
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
s6-rc.
If I were to work on a more official, better integrated solution, I
would
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
file
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
fix
daemons that don't use SIGTERM to shutdown instead...
--
Laurent
Received on Tue May 02 2017 - 09:30:58 UTC