search

unbit / uwsgi

uWSGI application server container
http://projects.unbit.it/uwsgi
Other
3.45k stars 691 forks source link

Actions taken upon receiving a SIGTERM #515

Closed illogicalextend closed 10 years ago

illogicalextend commented 10 years ago

Howdy. Wikipedia defines a SIGTERM as: "The SIGTERM signal is sent to a process to request its termination. Unlike the SIGKILL signal, it can be caught and interpreted or ignored by the process. This allows the process to perform nice termination releasing resources and saving state if appropriate. It should be noted that SIGINT is nearly identical to SIGTERM.". This definition is shared across many knowledge bases online and the perception by systems administrators.

However, it would seem that uWSGI is intentionally programmed to not terminate upon receiving a SIGTERM and instead, decides to reload its processes and continue to run. On first glance, this seems hypocritical to what a SIGTERM should actually do and thus adds complexity and confusion to systems administration in a production environment.

As such, I'm going to assume there must have been very good reasons that the devs decided to go down this route. Does anyone know what these reasons are or could point me towards some documentation with justification? So far all I can find is a reference in the docs that states "By default sending the SIGTERM signal to uWSGI means “brutally reload the stack” while the convention is to shut an application down on SIGTERM.". Thus it admits it goes against the convention, but does not explain why. Thanks.

unbit commented 10 years ago

In 2009 we did not have the master fifo, so the only way to manage instances were unix signals.

We fastly run out of them, so we needed to choose which one to use for "brutal reload" (that is a more important operation than 'shutdown' in an application server).

SIGINT -> absolutely not, as it is mapped to keyboard control-c, something vital in development

SIGQUIT -> semantically misleading (more than TERM do you agree ? maybe this is where we make the wrong decision....)

SIGTERM -> historycally called as a last resort before KILL, but completely shutting down app is less common than brutal reload.

As the other available signals were non-standard (read: only available in linux or in some solaris dialect) we decided for this (SIGTERM), having care to report it on the very top of this page (well at that time was on another url):

http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html

and in process managers docs (like upstart, emperor and similar).

Eventually --die-on-term "fixes" our choice inverting SIGQUIT for SIGTERM. Someone could argue that is even worst :) So, as always: it depends

illogicalextend commented 10 years ago

Sorry dude, I had only just seen your other reply and it was bad timing for me to make this thread now when you had already addressed the issue. Thanks for the info. I'll definitely look into deploying --die-on-term and do some further reading. Hopefully this argument can be declared in an .ini config file as well, rather than having to be passed in as an argument (guess I'll see if "die-on-term = true" works or continue experimenting from there).

unbit commented 10 years ago

definitely all of the command line options are available as config file directive:

http://uwsgi-docs.readthedocs.org/en/latest/Configuration.html

it is only a convention to write it with the -- prefix to specify we are referring to an option