nginx -s reload: Graceful Reload vs Restart
nginx -s reload signals the master process to re-read config and gracefully replace workers with no dropped connections.
Reload beats restart for deploys: existing connections drain on the old workers while new ones start on the new config. Always validate with nginx -t first.
What it does
nginx -s reload sends SIGHUP to the running master process. The master re-reads the configuration, starts new worker processes, and gracefully shuts down old workers once their in-flight requests finish. A restart (stop then start) drops all connections; reload does not.
Common usage
# validate first, then reload only if valid
nginx -t && nginx -s reload
# other control signals
nginx -s quit # graceful shutdown
nginx -s stop # fast shutdown
nginx -s reopen # reopen log files (for rotation)Options
| Signal | What it does |
|---|---|
| -s reload | Re-read config, gracefully replace workers (SIGHUP) |
| -s quit | Graceful shutdown, finish current requests (SIGQUIT) |
| -s stop | Fast shutdown, drop connections (SIGTERM) |
| -s reopen | Reopen log files, used for log rotation (SIGUSR1) |
In CI
Chain nginx -t && nginx -s reload so a bad config never reaches a live reload. If the new config fails to load, nginx keeps the old workers running and the reload is a no-op, so the gate is safe. In a systemd setup, prefer systemctl reload nginx which runs the config test first.
Common errors in CI
nginx: [error] open() "/run/nginx.pid" failed (2: No such file or directory) means no master process is running to signal; start nginx first. nginx: [error] invalid PID number "" in "/run/nginx.pid" means a stale or empty pid file. If a reload seems to do nothing, the config likely failed validation on load; check the error log for an [emerg] line.