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
Received on Tue May 02 2017 - 11:06:18 UTC