Controlling NGINX Processes at Runtime
Understand the NGINX processes that handle traffic, and how to control them at runtime.
This section describes the processes that NGINX starts at run time and how to control them.
Master and Worker Processes
NGINX has one master process and one or more worker processes. If caching is enabled, the cache loader and cache manager processes also run at startup.
The main purpose of the master process is to read and evaluate configuration files, as well as maintain the worker processes.
The worker processes do the actual processing of requests. NGINX relies on OS-dependent mechanisms to efficiently distribute requests among worker processes. The number of worker processes is defined by the worker_processes directive in the nginx.conf configuration file and can either be set to a fixed number or configured to adjust automatically to the number of available CPU cores.
To reload your configuration, you can stop or restart NGINX, or send signals to the master process. A signal can be sent by running the
nginx command (invoking the NGINX executable) with the
nginx -s <SIGNAL>
<SIGNAL> can be one of the following:
quit– Shut down gracefully (the
reload– Reload the configuration file (the
reopen– Reopen log files (the
stop– Shut down immediately (or fast shutdown, the
kill utility can also be used to send a signal directly to the master process. The process ID of the master process is written, by default, to the nginx.pid file, which is located in the /usr/local/nginx/logs or /var/run directory.
For more information about advanced signals (for performing live binary upgrades, for example), see Controlling nginx at nginx.org.