Killing and Signaling Processes
Despite its name, kill is really a signal-sending command — killing a process is only one of many things a signal can request. Signals are the kernel's mechanism for asynchronously notifying a process of an event: terminate, stop, reload configuration, or handle a hardware exception. Every process can install handlers for most signals, ignore them, or accept the kernel's default action, which makes understanding signal semantics essential before you start terminating things on a production system.
Cricket analogy: A third umpire's signal to the field isn't always "you're out" — it can also mean "review requested" or "check the boundary," and just as a fielding captain can appeal, ignore, or accept a decision, a process can catch, ignore, or accept the kernel's default ruling on a signal.
Common signals and their meaning
SIGTERM (15) is the default and polite signal sent by plain kill PID — it asks the process to shut down cleanly, giving it a chance to flush buffers, close file handles, and remove lock files. SIGKILL (9) is not delivered to the process at all in the userspace sense; the kernel immediately removes the process from the scheduler without giving it any chance to clean up, which is why it should be a last resort. SIGHUP (1) historically meant 'the controlling terminal hung up,' but many long-running daemons (nginx, sshd) repurpose it as a 'reload your configuration file' signal. SIGINT (2) is what a terminal sends when you press Ctrl+C. SIGSTOP (19) and SIGCONT (18) pause and resume a process respectively, and unlike SIGKILL, SIGSTOP cannot be caught, blocked, or ignored either.
Cricket analogy: SIGTERM is like a captain politely declaring the innings closed, letting batsmen finish their over; SIGKILL is the umpire calling stumps mid-ball with no time to react; SIGHUP is a bowling change that makes the fielding side reload its field placement.
# List all available signals with their numbers
kill -l
# Send SIGTERM (default, polite) by PID
kill 4521
# Send SIGKILL (forceful, last resort) by PID
kill -9 4521
kill -SIGKILL 4521 # equivalent, name form
# Reload a daemon's config without restarting it
kill -HUP $(pgrep nginx | head -1)
sudo systemctl reload nginx # preferred on systemd hosts
# Kill all processes matching a name
killall firefox
pkill -f 'python3 worker.py' # match against full command line
# Pause and resume a process
kill -STOP 4521
kill -CONT 4521kill vs killall vs pkill
kill operates strictly on numeric PIDs, which you typically obtain from ps or pgrep first. killall (on Linux, from psmisc) matches processes by exact executable name, so killall node kills every process literally named node. pkill is more flexible, matching against the process name by default but supporting -f to match anywhere in the full command line, -u to filter by user, and -9 for signal selection — making it powerful but also easier to accidentally match more processes than intended. Always dry-run with the companion pgrep (same matching logic, just lists PIDs instead of signaling them) before running pkill in anything you can't easily undo.
Cricket analogy: kill targeting a numeric PID is like dismissing a batsman by their specific jersey number; killall bans every player literally named "Kumar"; pkill -f searches the whole roster and staff for a partial match before acting, and pgrep checks that list first without removing anyone.
SIGKILL and SIGSTOP are the only two signals a process can never intercept, block, or ignore — this is a deliberate kernel design decision so there is always a way to forcibly stop any process, no matter how buggy or malicious its signal handlers are.
Reaching for kill -9 as the default is a common bad habit. It skips any cleanup code (temp file removal, database connection closing, in-flight write flushing), which can corrupt data files or leave stale locks behind. Always try SIGTERM first and only escalate to SIGKILL if the process ignores it after a reasonable wait.
killsends signals (default SIGTERM) to PIDs; it does not search by process name.- SIGTERM (15) requests graceful shutdown; SIGKILL (9) forces immediate termination with no cleanup.
- SIGKILL and SIGSTOP cannot be caught, blocked, or ignored by any process.
- SIGHUP is often repurposed by daemons to mean 'reload configuration' rather than 'terminal disconnected'.
killallmatches by exact process name;pkill/pgrepsupport pattern and full-command-line matching via -f.- Always attempt SIGTERM before SIGKILL to let processes clean up state and avoid data corruption.
Practice what you learned
1. What is the default signal sent by running `kill 1234` with no options?
2. Which two signals can never be caught, blocked, or ignored by a process?
3. What does `pkill -f 'python3 worker.py'` do differently from `pkill worker.py`?
4. Why is `kill -9` often discouraged as a first response?
5. Many daemons like nginx and sshd repurpose which signal to mean 'reload configuration'?
Was this page helpful?
You May Also Like
Monitoring Processes with ps and top
Learn to inspect running processes with ps snapshots and the interactive top monitor, reading CPU, memory, and state columns to diagnose system load.
Understanding Processes
Learn what a process is in Linux, how it relates to programs and the kernel, key attributes like PID/PPID and process states, and the parent-child process tree.
Background Jobs and nohup
Learn to run and manage background jobs with &, jobs, bg/fg, and disown, and keep long-running processes alive after logout using nohup and disown.
systemd and Managing Services
Learn how systemd manages services, sockets, and timers as units, and how to start, stop, enable, and inspect them with systemctl and journalctl.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics