How to Kill a Process in Linux

Learn how to find a Linux process by PID, send SIGTERM or SIGKILL, stop processes by name with pkill and killall, and troubleshoot permission and process-state issues.

A Linux process is an executing instance of a program. Every running process receives a numeric process ID, or PID. Commands that target one specific process commonly require its PID so that you can distinguish it from other running programs.

The kill command sends a signal to a process. A signal is a notification requesting an action such as graceful termination, configuration reload, stopping, or continuing. Despite its name, kill does not inherently force a process to exit.

Understand the kill command

The general form for sending a signal to a process is:

kill -SIGNAL PID

You can specify a signal by name, such as TERM or SIGTERM, or by number, such as 15:

kill -TERM 2486
kill -15 2486

If you omit the signal, kill sends SIGTERM, signal number 15:

kill 2486

SIGTERM requests a normal, graceful shutdown. A well-behaved application can catch this signal, close files, finish or roll back work, release resources, and then exit. This is why SIGTERM should normally be your first termination attempt.

To list the signal names and numbers supported by your shell's kill implementation, run:

kill -l

Common Linux signals

Signal name	Number	Typical use	Can the process handle or ignore it?	Key caution
SIGHUP	1	Often asks a daemon to reload its configuration	Usually yes; behavior depends on the program	It does not universally mean terminate or reload
SIGTERM	15	Requests graceful termination	Usually yes	The process may take time to clean up or may not respond
SIGKILL	9	Forces immediate termination	No; it cannot be caught or ignored	Normal cleanup and incomplete writes may be lost
SIGSTOP	Not portable as a single fixed number in this lesson	Stops a process without terminating it	No; it cannot be caught or ignored	The process remains stopped until continued
SIGCONT	Not portable as a single fixed number in this lesson	Resumes a stopped process	The process receives a request to continue	It only resumes a process that is stopped

SIGKILL and SIGSTOP cannot be caught or ignored. Most other signals can be handled by the program, although the program may choose not to do anything useful with them. Signal numbers other than the commonly used values above can vary between Unix-like systems, so signal names are often clearer.

Find a process PID

Use top

top is an interactive process-monitoring utility. It displays active processes, including their PIDs, owners, CPU use, memory use, and command names:

top

Look for the PID column and identify the row belonging to the process you intend to signal. Press q to exit top. A high CPU percentage can help locate a runaway process, but do not identify a target by CPU use alone; verify its command and owner first.

Use ps for detailed verification

ps lists process information. Once you have a candidate PID, verify it with:

ps -p 2486 -o pid,user,stat,cmd

Check the PID, account owner, process state, and complete command shown in the output. This protects against typing the wrong PID and helps detect that a PID has already been reused by a different process.

Search by name with pgrep and pidof

pgrep finds matching PIDs. The -a option displays each PID together with its command line:

pgrep -a dd

pidof is another option for obtaining PIDs associated with a program name:

pidof dd

Search results are candidates, not automatic confirmation. Use ps to inspect the exact process before sending a signal, especially when several instances have similar names.

Terminate a process by PID

Request a graceful shutdown

After verifying the PID, send the default SIGTERM:

kill 2486

You can make the intent explicit by naming the signal:

kill -TERM 2486

Wait briefly, then check whether the process still exists:

ps -p 2486 -o pid,user,stat,cmd

No process information generally means that the process exited. You can also search again with pgrep, but confirm that any result is the same intended command and not a newly started process.

Escalate to SIGKILL only when necessary

If the confirmed process does not exit after a reasonable wait and normal termination is not working, send SIGKILL:

kill -9 2486

SIGKILL is forceful and immediate from the kernel's perspective. The application cannot perform its normal cleanup, so buffered data may not be written and application state may become inconsistent. Always try SIGTERM first unless there is a specific, understood reason to require immediate termination.

Stop processes by name

Use pkill

pkill selects processes by name or pattern and sends a signal to each match. Use pgrep -a first to preview candidates:

pgrep -a worker

When the executable name is known and must match exactly, pkill -x is safer than a broad pattern:

pkill -x worker

You can specify a signal explicitly:

pkill -TERM -x worker

Use killall

killall sends the default signal to processes with a specified command name:

killall worker

Both name-based commands can affect multiple processes. Similar names, multiple application instances, and broad patterns can produce a wider match than intended. Prefer a verified PID when only one process should stop. Use killall only when you intentionally want to target every process with that command name and understand the impact.

Worked example: stopping a runaway dd process

Suppose a dd process is consuming excessive CPU. First open the process monitor:

top

Find the dd row, read its PID, and exit with q. In this example, assume the PID is 2486. Verify the target before acting:

ps -p 2486 -o pid,user,stat,cmd

If the output confirms that PID 2486 is the intended CPU-intensive dd process, request normal termination:

kill -TERM 2486

Check again after a short wait:

ps -p 2486 -o pid,user,stat,cmd

If the process remains unresponsive, and you accept the risk of interrupting its work, use SIGKILL:

kill -9 2486

Verify that it has exited. If the problem recurs, investigate why the dd command was started, what files or devices it was accessing, and whether storage or I/O problems are involved.

Permissions and sudo

Users can generally send signals to processes they own. Signaling a process owned by another account may require elevated privileges. Inspect ownership before acting:

ps -p 2486 -o pid,user,stat,cmd

If you are authorized to administer that process, use sudo:

sudo kill -TERM 2486

Do not terminate system or service processes merely because they use CPU or memory. Stopping the wrong process can interrupt networking, storage, authentication, logging, or other users' work. For a managed service, use its service manager when possible rather than repeatedly killing its underlying process.

Recommended escalation sequence

Step	Action	Expected outcome	When to continue
Identify and verify the process	Use `top`, `pgrep`, `pidof`, and `ps`	You know the exact PID, command, state, and owner	Continue only when the target is confirmed
Send SIGTERM	Run `kill PID` or `kill -TERM PID`	The application begins graceful shutdown	Continue if it remains present after a reasonable wait
Wait and recheck	Run `ps -p PID` again	You determine whether the process exited	Continue only if the same confirmed process remains
Send SIGKILL if necessary	Run `kill -9 PID`	The kernel forcibly terminates the process when possible	Use only after accepting cleanup and data-loss risks
Investigate repeated failures	Inspect logs, resource usage, I/O, process trees, and service configuration	The underlying cause is addressed	Do not treat repeated forced kills as a complete solution

Safety cautions

Prefer SIGTERM before SIGKILL. Graceful termination gives the application time to close files and clean up.
SIGKILL can cause data problems. It prevents normal application cleanup and may interrupt incomplete writes.
Uninterruptible I/O sleep can delay removal. A process waiting in an uninterruptible I/O state may not disappear immediately even after a kill request. Inspect the storage, network, or kernel-related I/O problem instead of assuming another signal will help.
Parent and child processes are separate. Killing a parent does not always terminate its children. Examine the process tree when a command has spawned workers or descendants, and decide which processes should actually stop.
Supervisors may restart processes. A service manager or supervisor can automatically start a process again after it exits. Manage the service through its service manager and inspect its configuration and logs.

Common problems and solutions

“No such process”

The process may have already exited, the PID may be mistyped, or the PID may have been reused. Search again, then verify the PID, owner, and command before retrying.

“Operation not permitted”

The process may belong to another user, or your account may lack permission to signal it. Confirm ownership with ps. Use sudo only when authorized, or ask the responsible administrator.

The process remains after SIGTERM

The application may be busy, hung, or performing cleanup. Wait briefly and inspect its status. If it remains the confirmed target and is unresponsive, use SIGKILL only after considering the risk of incomplete cleanup.

The process remains after SIGKILL

It may be stuck in uninterruptible I/O sleep. Inspect the process state and investigate the underlying storage or network I/O issue. Another kill signal will not normally solve that condition.

pkill or killall stopped too many processes

A broad name or pattern may have matched multiple instances. Preview with pgrep -a, use exact matching where appropriate, and prefer PID-based kill for a single target.

Commands at a glance

Command	Targets by	Typical use	Safety consideration
`top`	Interactive process list	Inspect PIDs, CPU use, and activity	Viewing is safe, but verify the target before acting
`ps`	PID or process criteria	Verify owner, state, and command	Use current information; PIDs can be reused
`pgrep`	Name or attributes	Find and preview matching PIDs	Matching output still needs confirmation
`kill`	One or more PIDs	Send a chosen signal	PID-based targeting is precise, but mistyped PIDs are dangerous
`pkill`	Name or pattern	Signal matching processes	Patterns can select multiple processes
`killall`	Command name	Signal every process with that name	Use only when broad termination is intentional

For related command-line fundamentals, review Linux topics and Bourne Again Shell Bash.