Operations 11 min read

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.

Open Source Linux
Open Source Linux
Open Source Linux
Understanding Nginx Process Architecture and Signal Management for Smooth Reloads

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 process

You 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 kill

Managing 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 1332

Command‑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 file

Configuration 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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Backendprocess managementLinux signalsConfiguration Reload
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.