Understand master and worker processes

Nginx normally runs one master process and one or more worker processes. The split exists for privilege and for uptime.

The master runs as root. It reads the configuration, opens the listening sockets (binding to port 80 requires privileges), and manages the workers. It never handles a client request itself.

The workers run as an unprivileged user, www-data on Ubuntu. Each worker handles many connections at once with an event-driven model, so a handful of workers can serve thousands of clients.

Look at the process tree with ps:

ps -ef --forest | grep [n]ginx
# root      1204     1  nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
# www-data  1205  1204  nginx: worker process
# www-data  1206  1204  nginx: worker process

The master’s parent is PID 1, and every worker’s parent is the master. Nginx labels each process in its command line, so you can tell them apart at a glance.

The number of workers comes from the worker_processes directive. The default packaged configuration sets it to auto, which means one worker per CPU core. You rarely need to change it.

Why this matters for reloads

When you reload the configuration, the master reads the new files and starts a fresh set of workers with the new settings. The old workers stop accepting new connections but keep serving the requests they already have, then exit. Clients never see a dropped connection.

This also means a reload does not instantly kill long-lived connections. An old worker holding an open download or WebSocket sticks around until that work finishes. If you see stale workers in ps after a reload, that’s usually why, not a bug.

Cross-check with systemd:

systemctl show nginx --property=MainPID
# MainPID=1204

The MainPID matches the master. Signals like reload go to the master, and it coordinates the workers.

One realistic mistake: killing a worker process directly to “fix” something. The master immediately spawns a replacement, so nothing changes, and you may have cut off in-flight requests. If a worker misbehaves, read the error log and act on the master, not on the workers.

Inspect the Nginx process tree on your test server. Identify the master PID, worker PIDs, users, and the process that systemd considers the main process.