Understanding Nginx Process Architecture and Signal Management for Smooth Reloads
This article explains Nginx's multi‑process design, the roles of master, worker, and cache processes, how to view and control them with Linux signals and command‑line tools, and the step‑by‑step reload procedure that ensures zero‑downtime configuration updates.
Nginx Process Architecture
Nginx uses a multi‑process model to achieve high availability and reliability. It consists of a master process that manages worker processes, one or more worker processes that handle client requests, and optional cache processes (cache manager and cache loader) used for reverse‑proxy caching.
Note: Multi‑process designs provide isolation of address spaces, which prevents failures in one process from affecting others, at the cost of higher CPU usage compared with multi‑threaded designs.
Example command to view the master and worker processes shows a master PID (e.g., 1325) and four worker processes sharing the same parent PID.
ps -ef | grep nginx | grep -v grep | grep -v php-fpm
root 1325 1 0 11:28 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 1332 1325 0 11:28 ? 00:00:00 nginx: worker process
nginx 1334 1325 0 11:28 ? 00:00:00 nginx: worker process
nginx 1335 1325 0 11:28 ? 00:00:00 nginx: worker process
nginx 1336 1325 0 11:28 ? 00:00:00 nginx: worker processYou can also list the listening sockets with lsof -i:80:
lsof -i:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1325 root 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1332 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1334 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1335 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1336 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)Signal Management
Linux Signal Mechanism
Signals are a form of inter‑process communication; for example, pressing Ctrl‑C sends SIGINT to terminate a program.
The kill -l command lists all supported signals. Common signals for Nginx include:
SIGHUP (kill -1 $PID): reload configuration.
SIGINT (kill -2 $PID): interrupt (Ctrl‑C).
SIGQUIT (kill -3 $PID): quit from keyboard.
SIGKILL (kill -9 $PID): force termination.
SIGUSR1 / SIGUSR2 (kill -10 $PID, kill -12 $PID): user‑defined.
SIGTERM (kill -15 $PID): graceful stop.
SIGCHLD (kill -17 $PID): child‑process status change.
kill -l # list signals
kill PID # kill a process
kill -9 1024 # force killManaging Nginx with Signals
The master process can be controlled via signals such as TERM, INT, QUIT, HUP, USR1, USR2, WINCH. For example, to stop Nginx gracefully: kill -s SIGTERM 1325 To reload configuration without dropping connections: kill -s SIGHUP 1325 Worker processes also receive signals (TERM, INT, QUIT, USR1, WINCH) but should generally be managed by the master.
kill -s SIGTERM 1332Command‑Line Options
Running nginx -h displays available options, such as:
nginx -h
nginx version: nginx/1.18.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
-?,-h : this help
-v : show version and exit
-V : show version and configure options then exit
-t : test configuration and exit
-T : test configuration, dump it and exit
-q : suppress non-error messages during configuration testing
-s signal : send signal to a master process: stop, quit, reopen, reload
-p prefix : set prefix path (default: /usr/local/nginx-1.18.0/)
-c filename : set configuration file (default: conf/nginx.conf)
-g directives : set global directives out of configuration fileConfiguration Reload Process
When nginx -s reload or a SIGHUP is sent to the master, the following steps occur:
Master receives HUP signal.
It validates the new configuration.
If necessary, it opens new listening sockets.
It spawns new worker processes using the updated configuration.
It sends QUIT to old workers.
Old workers finish existing connections then exit.
During reload, existing long‑running requests are allowed to complete while new workers handle incoming traffic, ensuring a seamless transition.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
