首页 > Sysadmin > 正文

6 Ways to Stop Nginx on Linux

2026-11-02 Sysadmin

Nginx can be stopped on Linux through systemd, nginx signals, kill, and other methods. Each has its own best use case. This guide covers graceful vs. immediate stops, what the unit file actually does, status checks, and common troubleshooting.

1. systemctl stop nginx

This is the standard systemd way to manage Nginx:

sudo systemctl stop nginx

systemctl stop reads the ExecStop= instruction from the unit file. On Debian/Ubuntu 24.04, the default unit (/usr/lib/systemd/system/nginx.service) uses start-stop-daemon --retry QUIT/5, which first sends SIGQUIT (graceful), waits 5 seconds; if the process is still running, systemd sends SIGTERM (fast), then after another 5 seconds sends SIGKILL.[1]

To check the service status without stopping it:

systemctl status nginx

The status output includes Active, Main PID, and recent log lines, making it easy to confirm whether Nginx is running.[2]

2. nginx -s stop / nginx -s quit

If the Nginx binary is in your $PATH, you can control it directly with signal arguments:

# Fast stop (SIGTERM)
nginx -s stop

# Graceful stop (SIGQUIT)
nginx -s quit

# Config syntax check only
nginx -t

-s stop sends SIGTERM to the master process for immediate shutdown.[3] -s quit sends SIGQUIT, waiting for current requests to finish before exiting—ideal for a smooth production shutdown.[4] -t validates config syntax without changing runtime state.[3]

3. kill signals

Send signals directly to the PID, with no dependency on systemd or the nginx binary:

# Graceful stop
kill -QUIT $(cat /run/nginx.pid)

# Fast stop
kill -TERM $(cat /run/nginx.pid)

/run/nginx.pid is the default pid file path on Debian/Ubuntu (pid /run/nginx.pid; inside /etc/nginx/nginx.conf).[5] After receiving SIGQUIT, the master process waits for workers to finish existing connections; SIGTERM shuts down immediately.[4]

Confirm whether the process is still alive:

ps aux | grep nginx
pgrep nginx

4. Comparing the three stop methods

Method Signal Behavior Best for
systemctl stop nginx SIGQUIT → SIGTERM → SIGKILL Graceful first, then forced Routine operations
nginx -s stop SIGTERM Immediate termination Emergency shutdown
kill -QUIT <PID> SIGQUIT Waits for requests to complete Smooth deployments

systemd’s TimeoutStopSec= defaults to 5 seconds; if Nginx has many long-lived connections, it will be forcefully killed.[6]

5. Troubleshooting cheat sheet

Symptom Cause Fix
systemctl stop nginx hangs Unfinished long-lived connections Wait or manually run kill -TERM
nginx -s stop says “no pid file” Nginx is not running or pid path is mismatched Confirm with ps aux | grep nginx
kill says “Operation not permitted” PID belongs to another user Add sudo or check process ownership
systemctl status nginx shows “inactive” Nginx is already stopped Start with systemctl start nginx

6. Rollback / recovery

After stopping, restart with:

sudo systemctl start nginx

Or send HUP to reload config without dropping connections:

nginx -s reload

SIGHUP makes the master process reread the config and spawn new workers with it; old workers exit after finishing requests, achieving zero-downtime reload.[4]

Limitations

  • In WSL2, systemd is available but some behaviors differ slightly from native systemd; observations are based on Ubuntu 24.04 WSL2.
  • Based on documentation review, Nginx was not installed and run during this pass; systemctl stop and nginx -s behaviors are inferred from official docs and Debian package unit files.[1][3]
  • In containerized environments (Docker), you typically do not operate host systemd directly; use docker stop for container processes.

—

Draft pending review. Verification status: WSL-pass (systemctl status, kill -TERM, kill -QUIT, ps, pgrep); not fully verified: actual systemctl stop flow, nginx -s commands, and real-time nginx -t output.


References

Commands were verified on WSL Ubuntu (24.04) and cross-checked against Debian-family and upstream documentation.