Use STOPSIGNAL SIGQUIT instead of SIGTERM #377
Description
Docker (and, therefore, Kubernetes) send SIGTERM as the default signal to stop containers. Docker will then wait 10 seconds before sending SIGKILL, Kubernetes will wait 30 seconds. They expect containers to exit gracefully within this grace period:
When you issue a docker stop command Docker will first ask nicely for the process to stop and if it doesn't comply within 10 seconds it will forcibly kill it. If you've ever issued a docker stop and had to wait 10 seconds for the command to return you've seen this in action
From: https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/
It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible!
In practice, this means your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
From: https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-terminating-with-grace
However, this is not what nginx does:
TERM, INT fast shutdown
QUIT graceful shutdown
From: http://nginx.org/en/docs/control.html
The Dockerfiles in this project use STOPSIGNAL SIGTERM (which actually isn't necessary since this is the default).
What this means in practice is that when Docker or Kubernetes decide to stop a container, nginx will die immediately, closing any connections straight away:
$ curl localhost
curl: (52) Empty reply from serverIt would be much healthier, and comply with the ethos of both Docker and Kubernetes if instead the nginx image made an effort to close all connections before shutting down. This can be achieved nicely with:
STOPSIGNAL SIGQUITI've verified this behaviour locally with this Dockerfile.