Processes and Runtime Control

This section describes the processes that NGINX starts at run time and how to control them.

In This Section

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 in the nginx.conf configuration file and can be fixed for a given configuration or automatically adjusted to the number of available CPU cores (see worker_processes).

Controlling NGINX

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 -s argument.

nginx -s signal

The signal value can be one of the following:

  • quit – Shut down gracefully
  • reload – Reload the configuration file
  • reopen – Reopen log files
  • stop – Shut down immediately (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 file, which is located in the /usr/local/nginx/logs or /var/run directory.

You can read more about advanced signals (for performing live binary upgrades, for example) in Controlling NGINX.


Download a 30 day free trial and see what you've been missing.


Got a question for the NGINX team?

< back


Sign up for beta

We'll be in touch with you about our NGINX Controller beta.