Linux Kill Process: Stop Processes by PID or Name

When a Linux app freezes or a background command stops responding, closing the window is not always enough. The process can keep running, hold files open, or block you from starting the program again.

Linux gives you several ways to stop it manually. Use kill when you know the process ID (PID), killall when you know the exact process name, and pkill when you want to match a name, user, or command pattern.

This guide explains how to kill a process in Linux by PID or name, how signals work, and when to use SIGTERM or SIGKILL.

Regular users can terminate only their own processes. The root user, or a user running commands with sudo, can terminate processes system-wide. The commands shown here work on any Linux distribution.

Quick Reference #

For a printable quick reference, see the kill cheatsheet .

Understanding Kill Signals #

kill, killall, and pkill send a given signal to specified processes or process groups. If no signal is specified, they default to 15 (TERM) for a graceful shutdown.

The signals you will reach for most often are these:

The numbers shown above apply to x86, ARM, and most other architectures. Some architectures assign different numbers, so use symbolic names such as SIGSTOP or STOP in portable commands and scripts.

Only SIGKILL and SIGSTOP cannot be caught, blocked, or ignored. Every other signal can be handled by the program itself, which is exactly why a process that shrugs off SIGTERM still goes down with SIGKILL.

Signals can be specified in three different ways:

• Using a number, such as -1
• With the SIG prefix, such as -SIGHUP
• Without the SIG prefix, such as -HUP

Use the -l option to list all available signals:

kill -l  # or killall -l

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR

The list continues with SIGSYS and the real-time signals from SIGRTMIN to SIGRTMAX. Those carry no fixed meaning and are defined by whichever application receives them.

Using the kill Command #

To terminate a process with the kill command, you first need to find its PID. You can do this using different commands, such as top, ps , pidof, and pgrep .

For example, use ps to search for a running Firefox process:

ps aux | grep firefox

zoe       1771  8.4  4.1 3418844 331420 ?      Sl   09:12   2:31 /usr/lib/firefox/firefox
zoe       1856  1.2  1.6 2318512 129640 ?      Sl   09:12   0:21 /usr/lib/firefox/firefox -contentproc -childID 1
zoe       1963  0.9  1.4 2298104 114228 ?      Sl   09:13   0:17 /usr/lib/firefox/firefox -contentproc -childID 2
zoe       3096  0.0  0.0    9040   2432 pts/0  S+   09:31   0:00 grep --color=auto firefox

The second column holds the PID, which is the number you pass to kill. The last line is the grep command itself, matching because the search term appears in its own command line, so ignore it.

If you are trying to free a port rather than close a program you can see on screen, our guide on finding which process is using a port shows how to get the PID first.

If Firefox has become unresponsive, find its process IDs with the pidof command:

pidof firefox

The command prints all matching Firefox PIDs:

2551 2514 1963 1856 1771

Start with the default TERM signal so the process has a chance to exit cleanly:

kill 2551 2514 1963 1856 1771

If the process ignores TERM, send the KILL signal:

kill -9 2551 2514 1963 1856 1771

SIGKILL cannot be caught or ignored, so it stops the process immediately. Use it only when the normal kill PID command does not work.

When you do not care about the individual numbers, hand the output of pidof straight to kill. Start with SIGTERM:

kill $(pidof firefox)

The shell replaces $(pidof firefox) with the list of PIDs before kill runs. If those processes ignore SIGTERM, add -9 as shown in the preceding example.

Checking Whether a Process Exists with kill -0 #

Signal 0 is a special case. kill runs its usual existence and permission checks but sends nothing, which makes it a cheap way to ask whether a PID is still around:

kill -0 1771

The command prints nothing and exits with status 0 when the process exists and you are allowed to signal it. If the PID is gone, it exits non-zero and prints an error:

bash: kill: (1771) - No such process

This is mostly useful inside scripts, where you test the exit status instead of reading the message:

if kill -0 "$pid" 2>/dev/null; then
  echo "Process $pid is still running"
else
  echo "Process $pid has exited or cannot be signaled"
fi

A zero exit status is not proof that the original program is still doing its job. A zombie keeps its PID until the parent reads its exit status, and the kernel reuses PIDs once they are free, so a long-running script can end up checking a completely different process than the one it started.

Sending SIGQUIT with kill -3 #

Signal 3 (SIGQUIT) terminates the process like SIGTERM, but it also asks the kernel to write a core dump, a snapshot of the process memory that a debugger can read later:

kill -3 1771

Whether a dump file actually appears depends on your system. The core size limit has to allow it, which you can check with ulimit -c, and the destination comes from kernel.core_pattern:

cat /proc/sys/kernel/core_pattern

Most desktop distributions pipe dumps into a crash handler rather than writing a core file next to the program, so read that value before you go looking for one.

Programs are free to install their own SIGQUIT handler, and the best known example is the Java virtual machine. Sending SIGQUIT to a Java process makes the HotSpot VM print a full thread dump, including any deadlocks it detects, to the standard output of that process, and the application keeps running afterwards:

kill -3 $(pidof java)

That behavior is why kill -3 turns up so often in Java troubleshooting notes. Pressing Ctrl+\ in the terminal that started the process sends the same signal.

Using the killall Command #

The killall command terminates all processes matching a given name. This is useful when a program has multiple running instances and you do not want to copy several PIDs.

Using the same scenario as before, send SIGTERM to all Firefox processes:

killall firefox

If Firefox still does not close, force it to stop:

killall -9 firefox

killall accepts several options, such as sending signals to processes owned by a specific user, matching process names against regular expressions, and filtering by process age. You can get a list of all options by typing killall --help in your terminal.

For example, to terminate Firefox processes owned by the user zoe, run:

sudo killall -u zoe firefox

Using the pkill Command #

pkill terminates processes that match the pattern given on the command line:

pkill firefox

The process name does not have to be an exact match. Partial matches work too, which makes pkill flexible but also easier to misuse.

Before using a broad pattern, preview the matches with pgrep :

pgrep -a firefox

1771 /usr/lib/firefox/firefox
1856 /usr/lib/firefox/firefox -contentproc -childID 1
1963 /usr/lib/firefox/firefox -contentproc -childID 2

pgrep -a prints the PID and the full command line for every process pkill would signal with the same pattern. If a line shows up here that you did not expect, narrow the pattern before running pkill.

To kill only Firefox processes owned by the user zoe, run:

pkill -u zoe firefox

If the process does not stop, add -9:

pkill -9 -u zoe firefox

Suspending and Resuming a Process #

Terminating a process is not always what you want. If a backup job is saturating the disk, or a compile is competing with something more urgent, you can pause it and pick it up later.

SIGSTOP suspends a process without ending it:

kill -STOP 1771

The process stays in the process table, keeps its memory and open files, and consumes no CPU. ps reports it in the T state:

ps -o pid,stat,cmd -p 1771

    PID STAT CMD
   1771 T    /usr/lib/firefox/firefox

Send SIGCONT when you want it to carry on where it left off:

kill -CONT 1771

Like SIGKILL, SIGSTOP cannot be caught or ignored, so a program has no way to refuse it and no chance to tidy up first. Avoid leaving a process suspended while it holds a lock or an open network connection, since everything waiting on it stays blocked too.

Jobs started from the current shell do not need a PID at all. Press Ctrl+Z to suspend the foreground job, which sends SIGTSTP, then list what is stopped:

jobs

[1]+  Stopped                 tar -czf backup.tar.gz /home/zoe

Resume the job in the foreground with fg %1, or in the background with bg %1. The same % notation works with kill, so kill %1 sends SIGTERM to job 1 and kill -9 %1 forces it to stop. Starting and managing jobs is covered in our guide on running Linux commands in the background .

Using xkill for GUI Applications #

If an X11 or XWayland application becomes unresponsive, you can use xkill to make the X server close the application’s connection by clicking on its window:

xkill

After running the command, your cursor changes to an “X”. Click the window you want to close. Losing the X server connection usually causes the application to exit, but xkill does not terminate the process directly.

Troubleshooting #

Process will not die with -9
If a process does not terminate even with SIGKILL (-9), it may be a zombie process. Zombie processes are already dead but still appear in the process table because their parent has not read their exit status.

To find zombie processes:

ps aux | awk '$8 ~ /Z/'

You cannot kill a zombie directly. Instead, kill its parent process or restart the system.

SIGKILL has no effect and the process shows state D
D is uninterruptible sleep, which usually means the process is blocked in a kernel call waiting on storage or a network filesystem. Signals are not delivered until it leaves that state, so kill -9 is queued rather than ignored. Check the state first:

ps -o pid,stat,cmd -p 1771

Fix the underlying I/O problem, such as a hung NFS mount or a failing disk. If the state never clears, a reboot is the only way out.

The process starts again right after you kill it
A service managed by systemd is restarted automatically when it exits, if its unit file sets Restart=. Killing the PID only triggers that restart. Stop the service instead:

sudo systemctl stop nginx

Permission denied
If you get a “Permission denied” error, the process belongs to another user. Use sudo to terminate it:

sudo kill PID

If the process still does not stop, use sudo kill -9 PID.

No such process
The PID has already exited. Confirm with ps -p 1771, or look up the current PID with pgrep -a firefox. This also happens when a program restarts under a new PID between the moment you looked it up and the moment you ran kill.

FAQ #

What is the difference between kill, killall, and pkill?
kill takes process IDs. killall takes an exact process name and signals every process running under that name. pkill matches its pattern against the process name as a regular expression, and the match does not have to be anchored, so pkill fire hits firefox along with anything else carrying those letters in its name.

How do I kill all processes belonging to a user?
Run sudo pkill -TERM -u zoe '.*' to signal every process owned by zoe, including their login shell. The .* pattern matches every process name. Add -9 only if the processes do not exit on their own.

Does kill -9 lose unsaved data?
It can. SIGKILL gives the program no chance to flush buffers, save open files, or clean up temporary files. Send the default SIGTERM first and give it a few seconds before escalating.

Conclusion #

To kill a process in Linux, use kill PID when you know the process ID, killall name for an exact process name, or pkill pattern when you need flexible matching. Start with the default SIGTERM signal, then use SIGKILL only when the process refuses to exit.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page