On Tue, May 02, 2017 at 08:51:19AM +0000, Laurent Bercot wrote: > 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.
I see. Now I also think that using a `shutdown-signal' file seems to be the least intrusive way. Considering the hangup problem, I think the format of the file can be described as something like > signal_1 timeout_1 signal_2 timeout_2 ... signal_n [timeout_n] where the last timeout, when present, indicates that SIGKILL shall be sent if that timeout elapses; the default is obviously > SIGTERM > 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... I think the problem is not daemons that don't use SIGTERM for shutdown, but daemons that use SIGINT/SIGQUIT/SIGTERM for subtly different flavours of shutdown. PostgreSQL does this, as well as nginx and php-fpm at least, but the signal semantics is again different in each case. Even if the use of SIGTERM is somehow unified to mean "fast but clean shutdown", the sysadmin might for some reason consider "wait for all clients to disconnect and then shut down cleanly" to be more appropriate for his use case. Since we aim to provide mechanisms instead of policies (when reasonable), I think adding this feature is acceptable. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C