kill is the Linux command that sends a signal to one or more processes identified by their process ID (PID). Despite its name, it does not only terminate programs: it delivers any Unix signal, and the default signal, SIGTERM, merely asks a process to exit cleanly. Among the tools for managing processes, it is the basic interface to the kernel’s kill() system call.
The kill command exists both as a shell builtin in Bash and other shells and as a standalone program, usually /bin/kill from procps or util-linux. The builtin can also address shell jobs such as %1, which makes it part of job control as well as of general process administration.
How the kill command delivers signals
When kill runs, it calls the kill() system call with a PID and a signal number. The kernel checks permissions, marks the signal as pending on the target process and wakes it if necessary. The process then handles the signal according to its disposition: run a custom handler, ignore it or apply the default action, which is usually termination.
Two signals are special. SIGKILL (9) and SIGSTOP (19 on x86) cannot be caught, blocked or ignored, so the kernel acts on them directly. Every other signal depends on the program’s cooperation, which is why a well-written server can shut down gracefully after SIGTERM but not after SIGKILL.
| PID value | Target | Example |
|---|---|---|
| Positive number | The process with that PID | kill 4321 |
| 0 | All processes in the caller’s process group | kill 0 |
| -1 | All processes the caller may signal | kill -9 -1 (dangerous) |
| Negative number | Every process in that process group | kill -TERM -4321 |
| %N (builtin only) | Shell job number N | kill %1 |
Signals most often sent with kill
Signals can be given by name or number, for example kill -TERM 1234, kill -s TERM 1234 or kill -15 1234. Names are more portable, because some signal numbers differ between architectures. kill -l lists all available signals.
| Signal | Number on x86 | Default action | Typical use |
|---|---|---|---|
| SIGTERM | 15 | Terminate | Polite request to exit; the default |
| SIGKILL | 9 | Terminate, cannot be caught | Last resort for a hung process |
| SIGHUP | 1 | Terminate | Many daemons reload configuration |
| SIGINT | 2 | Terminate | Same as pressing Ctrl+C |
| SIGSTOP and SIGCONT | 19 and 18 | Stop and resume | Pause and continue a process |
| SIGUSR1 and SIGUSR2 | 10 and 12 | Terminate | Application-defined actions such as log rotation |
The meaning of SIGHUP, SIGUSR1 and SIGUSR2 is defined by each program. Sending SIGHUP to a daemon may reload its configuration, while the same signal terminates an ordinary interactive program, so the documentation of the target program should be checked first.
kill compared with related commands
Several tools build on the same mechanism but select processes differently. kill needs exact PIDs, usually found with ps or pgrep, whereas other commands match by name or other attributes.
| Command | Selects processes by | Typical use |
|---|---|---|
| kill | PID, process group or job | Precise control of known processes |
| pkill | Name pattern, user, terminal and more | Signal all matching processes |
| killall | Exact process name | Stop every instance of a program |
| systemctl kill | systemd unit | Signal all processes of a service |
| OOM killer | Kernel memory heuristics | Automatic SIGKILL under memory exhaustion |
For services managed by systemd, systemctl stop or systemctl kill is preferable to plain kill, because systemd tracks all processes of a unit through cgroups and will not lose children that changed their PID or process group.
Using kill safely in practice
The established practice is an escalation sequence: ask first, wait, and force only when necessary. A forced kill skips cleanup, so temporary files, locks and partially written data may remain.
- Identify the process with
ps,pgrep -aor a process tree view, and verify the PID. - Send SIGTERM with
kill PIDand allow several seconds for a clean exit. - Check whether the process still exists with
kill -0 PID, which tests without sending a signal. - Only then send SIGKILL with
kill -9 PIDif the process ignores the request. - Inspect logs and leftover lock or PID files after a forced termination.
Permissions limit the command: an unprivileged user may signal only processes with the same user ID, while root, or a process with the CAP_KILL capability, may signal almost any process. PID namespaces in containers further restrict which processes are visible.
Using kill in shell scripts
Scripts use kill to stop background workers and to clean up after themselves. A common pattern stores the PID of a background job from the special variable $!, then signals it in a trap handler when the script exits, so no orphaned children remain after an error or an interruption.
The exit status of kill is also useful. It returns 0 when at least one signal was delivered and a non-zero value when the process does not exist or permission is denied. Combined with kill -0, this allows a script to wait in a loop for a clean shutdown and to escalate only after a timeout, which mirrors what service managers do automatically.
Signals sent to a negative PID reach a whole process group, which is the reliable way to stop a pipeline or a program together with all of its child processes.
Pitfalls and misconceptions
- kill -9 is not a first choice. It prevents cleanup and can corrupt data that a graceful shutdown would have saved.
- Zombie processes cannot be killed. They are already dead; the parent must reap them, or the parent itself must exit.
- Processes in uninterruptible sleep (state D) do not respond even to SIGKILL until their I/O completes.
- PID reuse means a stored PID may later belong to another process, so scripts should verify before signaling.
- kill -1 with SIGKILL as root can stop almost every process on the system, including the session running the command.
The short version
The kill command is a way to send a message to a running program. Each program has a number, and kill delivers the message to that number. The most common message politely asks the program to close.
Most programs listen and finish their work before exiting. If a program is frozen, a stronger message forces it to stop at once. That works, but the program gets no chance to tidy up, much like pulling a plug instead of using the off switch.
Where it makes a difference
An administrator notices that a web application server on a Linux host is using 100 percent of one CPU core and no longer answers requests. Running pgrep -a java shows the main process with PID 28417.
The administrator first sends kill 28417, which delivers SIGTERM. The application logs that it is closing database connections, but after 30 seconds the process is still present, as kill -0 28417 confirms. A thread dump obtained earlier with SIGQUIT shows a deadlock. The administrator then sends kill -9 28417, and the process disappears immediately.
Because the service is managed by systemd, it restarts automatically within seconds. The administrator removes a stale lock file left behind by the forced stop. The outcome is a short outage of under a minute and a recorded deadlock for the developers to fix.