Hello,

It turns out that the way that Debian implements stopping nginx is by
sending it, through the start-stop-daemon's --retry option a SIGQUIT to
nginx, which is interpreted by nginx as a "gradeful shutdown", but it
turns out is not very clean way to shutdown, and nginx developers think
that nobody should be doing this[0]. The other stop method is the
SIGTERM, which is what they are expecting people to send to shutdown
nginx and it properly cleans up the sockets.


If you configure nginx to use a unix socket for a listener, then when
you restart, or stop and then start, nginx, it will fail to start
because it will not clean up the listening socket because it was stopped
with the 'SIGQUIT' method[1][2].

Additionally, in version 1.6.2-3 of the package upload this changelog
entry appears:

 * debian/nginx-common.nginx.init:
    + Gracefully stop nginx by default, we are switcing to a configurable
      STOP/5/TERM/5/KILL/5 schedule. We are now in sync with the systemd
      service file. (Closes: #762708)

However, the initscript and the systemd service file are *not* in
sync. The systemd service file has just '--retry QUIT/5' and the
initscript has 'QUIT/5/TERM/5/KILL/5', so these are most definitely not
in sync.

I've attached patches that syncs these up, and has them do a SIGTERM
instead of a SIGQUIT because it appears to be more "graceful" and will
properly clean up sockets.

micah

0. https://trac.nginx.org/nginx/ticket/753#comment:5
1. https://trac.nginx.org/nginx/ticket/753 and
2. https://trac.nginx.org/nginx/ticket/952).

I'm marking this closed because the fix has been released.

SIGQUITs are still being sent, and sockets are not being cleaned up, as of 1.10.3-1+deb9u1 and 1.13.3-1~bpo9+1.

Sorry, that commit does not fix the problem with non-removed unix
sockets and there is some confusion with patches attached to the bug report.

+ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5
--pidfile /run/nginx.pid

line causes graceful stop, survived sockets, and so failure to start
next time. If the intention is fast shutdown as suggested in [1] then
stop retry schedule should be TERM/5. STOP_SCHEDULE in
debian/nginx-common.nginx.init should be changed accordingly e.g. to
TERM/10/KILL/5. There should be no QUIT in both cases. Also there is
some mess in comments in the file debian/nginx-common.nginx.service and
in the changelog.Debian and the commit messages, nobody sends the namely
SIGSTOP signal.

Sorry, I do not provide patch due to I am a bit lazy to setup
environment and check that patched package will be successfully built.

I was considering an additional hook in init scripts for removing
sockets after graceful stop. There are might be rare cases when it is
desirable to wait till finishing of some long transaction so graceful
shutdown is preferable. Unfortunately I do not see an easy way to get
list of stale sockets from the init scripts.

[1] https://trac.nginx.org/nginx/ticket/753#comment:5

This bug is still present for me in version 1.14.1-1~bpo9+1.

I can confirm this as well; nginx 1.14.1-1~bpo9+1 does not restart
properly as sockets are not removed upon stop and nginx complains that
the address is already in use when restarting.

----------------------------------
----------------------------------
Forumhome sucht Praktikanten im Bereich Online-Marketing, Webdesign und
Webbasierte Softwareentwicklung!
Interesse? Informieren Sie sich unter
http://de.forumhome.com/content/10-jobs und schicken Sie uns Ihre
Bewerbungsunterlagen an jobs@forumhome.com
Wir freuen uns auf Sie!
----------------------------------
----------------------------------

Diese E-Mail enthält vertrauliche oder rechtlich geschützte Informationen.
Wenn Sie nicht der beabsichtigte Empfänger oder dessen Vertreter sind,
informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail.
Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der
enthaltenen Informationen ist nicht gestattet.

The information contained in this message is confidential or protected
by law. If you are not the intended recipient, please contact the sender
and delete this message.
Any unauthorised copying of this message or unauthorised distribution of
the information contained herein is prohibited.

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

According to the nginx changelog, it's been fixed in 1.19.1

part of changelog http://nginx.org/en/CHANGES

Changes with nginx 1.19.1                                        07 Jul 2020

    *) Change: the "lingering_close", "lingering_time", and
       "lingering_timeout" directives now work when using HTTP/2.

    *) Change: now extra data sent by a backend are always discarded.

    *) Change: now after receiving a too short response from a FastCGI
       server nginx tries to send the available part of the response to the
       client, and then closes the client connection.

    *) Change: now after receiving a response with incorrect length from a
       gRPC backend nginx stops response processing with an error.

    *) Feature: the "min_free" parameter of the "proxy_cache_path",
       "fastcgi_cache_path", "scgi_cache_path", and "uwsgi_cache_path"
       directives.
       Thanks to Adam Bambuch.
**) Bugfix: nginx did not delete unix domain listen sockets during
graceful shutdown on the SIGQUIT signal. *The last one which is indicate to the bug related
**