On Thu, Nov 10, 2016 at 10:42:36PM +0100, Michael Biebl wrote:
On Tue, 8 Nov 2016 11:20:45 +0200 Christos Trochalakis
<[email protected]> wrote:
On Fri, Apr 15, 2016 at 06:54:55PM +0200, Laurent Bigonville wrote:
>Package: nginx
>Version: 1.6.2-3
>Severity: normal
>User: [email protected]
>
>Hi,
>
>Wouldn't it be better to use KillSignal=SIGQUIT in the .service file
>rather than using this hack?
>
>ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile
/run/nginx.pid
>
>Is it necessary really necessary to send QUIT, then TERM and then KILL?
>
By using KillSignal=SIGQUIT systemd would forcibly (SIGKILL) nginx after
the timeout is reached.
SIGQUIT triggers graceful shutdown so it waits for all existing client
connections to terminate. If for example you have websocket or SSE long
running clients you will hit the timeout. In such cases we don't want
systemd to SIGKILL nginx.
The current solution fallbacks to SIGTERM that forces systemd to close
existing clients and terminate.
Would
ExecStop=/bin/kill -QUIT $MAINPID
work?
This would first send SIQUIT to the main process, after TimeoutStopSec=
it would send SIGTERM to all remaining processes and after another
TimeoutStopSec=, SIGKILL.
Is this the behaviour you want?
It feels a bit more systemdish to me then involving start-stop-daemon
If I remember correctly that wont do it. Systemd expects the ExecStop=
command to block until the service is stopped, or it fallbacks to
SIGTERM. According to the systemd.service(5):
After the commands configured in this option are run, all processes
remaining for a service are terminated according to the KillMode=
setting.
I remember testing this a while back and decided to use
start-stop-daemon which has the ability to block until the service is
stopped:
https://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=caee1c2a
