What is the difference between the Nginx master process and worker processes?
Understand the difference between the Nginx master and worker processes, how privilege separation works, and how graceful reloads keep your server online.
Expected Interview Answer
The Nginx master process is a single privileged supervisor that reads configuration, binds ports, and manages the pool of worker processes, while the worker processes are the non-privileged children that actually accept connections and handle client requests.
The master runs as root so it can bind privileged ports (80/443) and read certificates, then spawns workers that drop to an unprivileged user. Each worker runs an event loop that handles thousands of concurrent connections asynchronously; the number of workers is set by worker_processes, typically one per CPU core. The master never handles traffic itself — it performs lifecycle tasks like reloading configuration, rotating logs, and restarting crashed workers via signals.
- Privilege separation: only the master runs as root
- Zero-downtime config reloads via graceful worker replacement
- Fault isolation: a crashed worker is respawned without dropping the whole server
- Scales across CPU cores by running one worker per core
- Non-blocking event loops in workers handle high concurrency efficiently
AI Mentor Explanation
The master process is the team captain and coach who reads the game plan, wins the toss, and sets the field, but never faces a single ball himself. The worker processes are the eleven fielders and bowlers on the pitch who actually chase every delivery. If a fielder is injured, the captain brings on a substitute without stopping the match, exactly as the master respawns a crashed worker while play continues.
Step-by-Step Explanation
Step 1
Master starts as root
On startup the master reads nginx.conf, binds listen sockets on privileged ports, and loads TLS certificates while running as root.
Step 2
Workers are forked
The master forks worker_processes children which drop privileges to the configured unprivileged user (e.g. nginx or www-data).
Step 3
Workers handle traffic
Each worker runs an independent event loop, accepting connections and serving requests without blocking on I/O.
Step 4
Master supervises
The master watches workers, respawns any that crash, and coordinates lifecycle actions through Unix signals.
Step 5
Graceful reload
On SIGHUP the master starts new workers with the new config and gracefully shuts old ones down after they finish in-flight requests.
What Interviewer Expects
- Clear statement that the master supervises and workers serve traffic
- Understanding of privilege separation (master as root, workers unprivileged)
- Knowledge that worker_processes usually maps to CPU cores
- Awareness of the event-driven, non-blocking worker model
- Explanation of graceful reload and worker respawn on crash
Common Mistakes
- Claiming the master process handles client requests
- Saying more workers always means more performance regardless of cores
- Confusing worker processes with threads
- Not knowing workers run as an unprivileged user
- Thinking a config reload restarts the entire server and drops connections
Best Answer (HR Friendly)
“Nginx runs one boss process called the master that reads the settings and keeps everything organized, and several helper processes called workers that actually answer visitors' requests. The boss never talks to visitors directly; it just makes sure the helpers are running and restarts any that stop.”
Code Example
# nginx.conf — top-level (main) context
user nginx; # workers drop to this unprivileged user
worker_processes auto; # one worker per CPU core
events {
worker_connections 1024; # max simultaneous connections per worker
}
# Gracefully reload config without dropping connections:
# nginx -s reload (sends SIGHUP to the master)Follow-up Questions
- Why does the master process need to run as root?
- What happens internally when you run 'nginx -s reload'?
- How does 'worker_processes auto' decide the number of workers?
- What is the role of worker_connections?
- How does Nginx achieve high concurrency without spawning a thread per request?
MCQ Practice
1. Which process actually accepts and serves client connections in Nginx?
Workers run the event loops that accept connections and serve requests; the master only supervises them.
2. Why is the Nginx master process typically run as root?
Root privileges let the master bind ports below 1024 and read protected TLS keys before dropping workers to an unprivileged user.
3. A recommended value for worker_processes is usually?
Matching workers to CPU cores (worker_processes auto) balances parallelism against context-switching overhead.
Flash Cards
What does the Nginx master process do? — Reads config, binds ports, loads certs, and supervises workers — it never serves client traffic.
What do Nginx worker processes do? — Run event loops that accept connections and handle client requests, as an unprivileged user.
How many workers should you run? — Typically one per CPU core, set with 'worker_processes auto'.
What happens on 'nginx -s reload'? — The master starts new workers with the new config and gracefully retires old ones after in-flight requests finish.