Use signals deliberately

Signals ask a process to perform an action. They do not all mean “stop now.” Sending the wrong one, or sending the right one to the wrong PID, turns a small problem into a bigger one.

The three you’ll actually use:

SIGTERM (kill PID, the default) allows normal shutdown. The process can finish requests, flush buffers, and remove its lock files. This is always your first choice.

SIGHUP often requests reload — re-read config without dropping connections — but behavior is application-specific. nginx reloads on it. A process with no handler just dies. Check the application docs before assuming.

SIGKILL (kill -9) cannot be handled and prevents cleanup. The kernel removes the process immediately. No flush, no lock removal, no goodbye to clients. It’s the last resort for a process that ignored SIGTERM, not the first move.

Prefer the service manager

Use systemctl when systemd owns the process. It signals the right PIDs, in the right order, and tracks the result:

sudo systemctl reload nginx     # sends the unit's configured reload signal
sudo systemctl stop myapp       # SIGTERM, waits, then escalates for you

To see what a stop will do before you do it:

systemctl show myapp -p ExecMainPID -p KillSignal -p TimeoutStopUSec

ExecMainPID=2143
KillSignal=15
TimeoutStopUSec=1min 30s

That reads: SIGTERM (signal 15) goes to the service, and if it’s still alive after 90 seconds, systemd escalates to SIGKILL itself. You rarely need to run kill -9 by hand on a managed service.

If you must signal directly, verify the PID first:

ps -o pid,ppid,user,cmd -p 2143
kill 2143          # SIGTERM
kill -0 2143 && echo still-running || echo gone

kill -0 sends no signal at all — it just checks the process still exists, which makes it a clean way to verify the stop worked.

The trap: killing a PID you copied from an old terminal or a stale log. PIDs get reused. The worker you meant to kill exited an hour ago, and 2143 now belongs to a backup job mid-write. Always re-check what a PID is right now before signaling it. And on systemd services, remember that killing the main process by hand often just triggers Restart=always — you didn’t stop the service, you restarted it and confused the journal.