kill

What it does

kill sends a signal to one or more processes identified by PID. Despite the name, it doesn't always terminate a process — "kill" is really shorthand for "send a signal," and the specific signal (SIGTERM, SIGKILL, SIGHUP, SIGSTOP, SIGCONT, and dozens more) determines what actually happens. The default signal, if none is specified, is SIGTERM (15), which asks a process to shut down gracefully rather than forcing it to stop.

Beginner examples

• kill 1234 — send SIGTERM to PID 1234, asking it to terminate gracefully
• kill -9 1234 — send SIGKILL, force-terminating PID 1234 immediately
• kill -l — list all available signal names and numbers
• kill -HUP 1234 — send SIGHUP, often used to reload a daemon's configuration

kill -9 1234

Advanced examples

• Signal multiple PIDs at once: kill -9 1234 5678 9012
• Pause a runaway process without killing it, then resume it later: kill -STOP 1234 then kill -CONT 1234
• Reload a service's config without a full restart: kill -HUP $(pgrep nginx | head -1)
• Specify the signal by name explicitly for clarity in scripts: kill -s TERM 1234
• Confirm a process actually exited after signaling it: kill -9 1234; sleep 1; ps -p 1234

kill -TERM $(pgrep -f my_worker.py)

Common mistakes

• Reaching for kill -9 first instead of trying plain kill (SIGTERM) first — SIGKILL skips cleanup entirely, which can leave temp files, locks, or database connections in a bad state; SIGTERM gives well-behaved programs a chance to shut down properly.
• Passing a process name instead of a PID — kill only accepts PIDs (or job specs like %1); for names, use pkill or killall instead.
• Not checking whether the process actually terminated after sending SIGTERM — some programs ignore it or take a while to clean up, and immediately assuming success can hide a stuck process.
• Confusing kill -9 (a real signal) with somehow being "more forceful" SIGTERM — SIGKILL isn't a stronger version of SIGTERM, it's a different signal entirely, one the target process cannot intercept, catch, or ignore.

Tips

• Try kill <pid> (SIGTERM) before kill -9 <pid> (SIGKILL) — well-written programs handle SIGTERM to save state or close connections cleanly; only escalate to -9 if the process doesn't respond after a few seconds.
• Use kill -l when you forget a signal's number or name; signal numbers can even differ slightly between architectures for some of the higher-numbered signals.
• kill -0 <pid> sends no actual signal but returns an exit status you can check — handy in scripts to test whether a PID is still running without affecting it.
• Combine with pgrep to find the PID first: kill $(pgrep -f my_script.py) instead of hardcoding a PID you looked up manually.

Best practices

• Default to SIGTERM and only escalate to SIGKILL (-9) after confirming the process didn't respond — this is especially important for anything touching a database or writing files, where abrupt termination can corrupt state.
• In deployment/orchestration scripts, send SIGTERM and then wait (with a timeout) before falling back to SIGKILL, mirroring how systemd and container runtimes shut services down.
• Prefer signaling by PID looked up freshly (e.g. via pgrep) rather than a cached or hardcoded PID, since PIDs are reused and a stale one could belong to an unrelated process.
• Understand which signals a target application handles specially (many daemons treat SIGHUP as "reload config") before assuming a signal always means "stop."

Real-world use cases

• Gracefully restarting a web server's configuration without dropping active connections, via kill -HUP <pid> if the server supports it.
• Terminating a hung script or unresponsive process that isn't cleaning up on its own, first with SIGTERM, then SIGKILL if it doesn't exit.
• Temporarily pausing a resource-hungry background job with SIGSTOP during a maintenance window, then resuming it later with SIGCONT instead of killing and restarting it.

Common interview questions

• What's the difference between SIGTERM and SIGKILL? SIGTERM (15) is a polite request a process can catch, handle, and use to clean up before exiting; SIGKILL (9) can't be caught, blocked, or ignored — the kernel terminates the process immediately with no chance to clean up.
• What does kill -HUP do to a running daemon and why? By convention, many daemons (nginx, sshd) interpret SIGHUP as "reload your configuration file" rather than its original meaning of "terminal hung up," letting them apply config changes without a full restart.
• How would you check if a process is still alive without actually signaling it? kill -0 <pid> sends no signal but returns a zero exit status if the process exists (and you have permission to signal it), non-zero otherwise.