jingrow/gunicorn
1
0
Fork 0
mirror of https://github.com/frappe/gunicorn.git synced 2026-01-14 11:09:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #843 from msabramo/patch-1

Browse Source 
signals.rst: Improve English slightly
This commit is contained in:
Berker Peksag 2014-08-08 08:52:05 +03:00
commit 30fe550d10
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/source/signals.rst
View File

@ -1,12 +1,12 @@
.. _signals: .. _signals:
================ ================
Signals Handling Signal Handling
================ ================
A brief description of the signals handled by Gunicorn. We also document the A brief description of the signals handled by Gunicorn. We also document the
signales used internally by Gunicorn to communicate with the workers. With the signals used internally by Gunicorn to communicate with the workers. With the
exception of TTIN/TTOU the signals handling match the behaviour of `nginx exception of TTIN/TTOU the signal handling matches the behaviour of `nginx
<http://wiki.nginx.org/CommandLine>`_. <http://wiki.nginx.org/CommandLine>`_.
Master process Master process
@ -42,7 +42,7 @@ automatically respawned.
Reload the configuration Reload the configuration
======================== ========================
the signal HUP can be used to reload the Gunicorn configuration on the The ``HUP`` signal can be used to reload the Gunicorn configuration on the
fly. fly.
:: ::
@ -57,7 +57,7 @@ fly.
2013-06-29 06:26:55 [20704] [INFO] Booting worker with pid: 20704 2013-06-29 06:26:55 [20704] [INFO] Booting worker with pid: 20704
Sending an **HUP** signal will reload the configuration, start the new Sending a **HUP** signal will reload the configuration, start the new
worker processes with a new configuration and gracefully shutdown older worker processes with a new configuration and gracefully shutdown older
workers. If the application is not preloaded (using the ``--preload`` workers. If the application is not preloaded (using the ``--preload``
option), Gunicorn will also load the new version. option), Gunicorn will also load the new version.
@ -70,7 +70,7 @@ upgrading to a new version or adding/removing server modules), you can
do it without any service downtime - no incoming requests will be do it without any service downtime - no incoming requests will be
lost. Preloaded applications will also be reloaded. lost. Preloaded applications will also be reloaded.
First, replace old binary with a new one, then send **USR2** signal to the First, replace the old binary with a new one, then send the **USR2** signal to the
master process. It renames its .pid file to .oldbin (e.g. master process. It renames its .pid file to .oldbin (e.g.
/var/run/gunicorn.pid.oldbin), then executes a new binary, /var/run/gunicorn.pid.oldbin), then executes a new binary,
which in turn starts a new master process and the new worker processes:: which in turn starts a new master process and the new worker processes::
@ -88,22 +88,22 @@ which in turn starts a new master process and the new worker processes::
At this point, two instances of gunicorn are running, handling the At this point, two instances of gunicorn are running, handling the
incoming requests together. To phase the old instance out, you have to incoming requests together. To phase the old instance out, you have to
send **WINCH** signal to the old master process, and its worker send the **WINCH** signal to the old master process, and its worker
processes will start to gracefully shut down. processes will start to gracefully shut down.
At this point you can still revert to the old server because it hasn't closed its listen sockets yet, by following these steps: At this point you can still revert to the old server because it hasn't closed its listen sockets yet, by following these steps:
- Send HUP signal to the old master process - it will start the worker processes without reloading a configuration file - Send the HUP signal to the old master process - it will start the worker processes without reloading a configuration file
- Send TERM signal to the new master process to gracefully shut down its worker processes - Send the TERM signal to the new master process to gracefully shut down its worker processes
- Send QUIT signal to the new master process to force it quit - Send the QUIT signal to the new master process to force it quit
If for some reason new worker processes do not quit, send KILL signal to If for some reason the new worker processes do not quit, send the KILL signal to
them after the new master process quits, the old master process removes them after the new master process quits, the old master process removes
.oldbin suffix from its .pid file, and everything is exactly as before .oldbin suffix from its .pid file, and everything is exactly as before
the upgrade attempt. the upgrade attempt.
If an update is successful and you want to keep the new server, send If an update is successful and you want to keep the new server, send
the TERM signal to the old master process to leave only new server the TERM signal to the old master process to leave only the new server
running:: running::
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND