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@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: https://www.mail-archive.com/supervision@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