How to Kill a Process in Linux: Commands, Signals, and System Monitoring

Knowing how to kill a process in Linux is one of those practical skills that matters most when something has already gone wrong — an application has frozen, a runaway script is consuming all CPU, or a service refuses to respond. Linux provides multiple tools for identifying problematic processes and terminating them cleanly or forcefully. This guide covers the complete workflow: finding the process, understanding what it is doing, and choosing the right termination method.

Finding a Process: ps and top

Before killing a process, you need its process ID (PID). Every running process on a Linux system has a unique PID assigned by the kernel at startup.

The ps command (process status) lists running processes. Without arguments it shows only processes in the current terminal session. The most useful invocation shows all processes from all users in a full format:

ps aux

The output columns include: USER (process owner), PID, %CPU, %MEM, COMMAND (full command line). Filter with grep to find a specific process:

ps aux | grep firefox

The ps command linux output is a snapshot — it shows the state at the moment you ran the command. For live monitoring, use top.

top Command Linux: Real-Time Process Monitoring

The top command linux provides a continuously updating view of running processes, sorted by CPU usage by default. The header section shows system-wide statistics: uptime, number of running processes, load averages, and a breakdown of CPU time categories.

Useful top keyboard shortcuts:

• M — sort by memory usage
• P — sort by CPU usage (default)
• k — kill a process (top prompts for PID and signal)
• q — quit
• 1 — toggle per-CPU breakdown in header

For a more modern alternative, htop provides a color-coded, navigable interface with mouse support. Install it with sudo apt install htop. It shows CPU usage as bar graphs, allows horizontal scrolling for long command lines, and lets you kill processes by selecting them and pressing F9.

Checking CPU and Memory Usage

check cpu usage linux

Understanding what is consuming CPU before killing processes helps you make the right decision. A process at 100% CPU is not always a problem — a video encoder or compilation job should use all available CPU.

Check overall CPU usage:

top -bn1 | grep "Cpu(s)"

The output shows percentage of time spent in user space (us), kernel space (sy), and idle (id). A high sy value with low us often indicates I/O wait rather than actual computation.

For a per-process CPU report without the interactive interface:

ps aux --sort=-%cpu | head -10

This lists the ten highest CPU-consuming processes, sorted descending.

check memory usage linux

Linux memory usage reporting is often misread. The free command shows memory in a way that looks alarming but is normal:

free -h

Sample output:

              total        used        free      shared  buff/cache   available
Mem:           16Gi        8.2Gi       1.1Gi     512Mi       6.7Gi      7.0Gi

The “available” column (not “free”) is what matters. Linux aggressively uses RAM for filesystem caching (buff/cache). This cached memory is immediately reclaimed when applications need it — low free memory with high cache is healthy, not a problem.

For linux memory usage by process:

ps aux --sort=-%mem | head -10

The %MEM column shows each process’s share of total physical memory. The VSZ column shows virtual memory size (including memory-mapped files and shared libraries). RSS shows actual physical RAM used.

Understanding Linux Process Signals

The kill command sends signals to processes. A signal is a software interrupt that tells the process to do something. Knowing which signal to use determines whether the process gets a chance to clean up or is terminated immediately.

Signal	Number	Name	Behavior
SIGTERM	15	Terminate	Asks process to exit cleanly (default)
SIGKILL	9	Kill	Forces immediate termination — cannot be ignored
SIGHUP	1	Hang up	Reload configuration (daemons)
SIGINT	2	Interrupt	Same as Ctrl+C
SIGSTOP	19	Stop	Pause process (cannot be ignored)
SIGCONT	18	Continue	Resume a paused process

Always try SIGTERM before SIGKILL. SIGTERM gives the process an opportunity to close file handles, flush buffers, and remove lock files. SIGKILL bypasses all of this and can leave corrupted data or stale lock files behind.

The kill Command: Terminating by PID

The basic kill command sends SIGTERM to a process by PID:

kill 1234

Send a specific signal by number or name:

kill -9 1234          # SIGKILL — force terminate
kill -15 1234         # SIGTERM — graceful terminate (same as default)
kill -SIGTERM 1234    # Same using signal name
kill -HUP 1234        # SIGHUP — typically reloads config

Administrators often use SIGHUP to reload daemon configurations without a full restart:

kill -HUP $(pgrep nginx)

The pgrep command looks up process IDs by name, making it cleaner than piping ps through grep and cutting out the PID column.

killall and pkill: Killing by Name

When a process has spawned multiple instances or you do not want to look up individual PIDs, killall and pkill offer name-based termination.

killall matches the exact process name:

killall firefox
killall -9 firefox       # Force kill all firefox processes

pkill uses a pattern match and supports additional filtering:

pkill firefox            # Matches processes with firefox in the name
pkill -u alice python    # Kill python processes owned by alice

pkill is more flexible than killall for situations where the process name contains spaces or where you need to filter by user.

For processes that need root privileges to kill — system daemons, kernel threads — prefix the kill command with sudo:

sudo kill -9 1

Be careful: sending SIGKILL to PID 1 (the init process) can cause a system hang. The guide on how to get root privileges in Linux explains when sudo is appropriate and how to configure it safely.

Identifying Runaway Processes and When to Kill Them

Not every high-CPU or high-memory process should be killed. Context matters. Before sending a signal, check what the process actually is:

cat /proc/1234/cmdline | tr '\0' ' '    # Full command line of PID 1234
ls -la /proc/1234/exe                   # Executable path
cat /proc/1234/status                   # Detailed process status

The /proc filesystem contains a directory for every running process with detailed information about memory maps, file descriptors, and resource usage. This information helps distinguish a legitimate long-running task from an actual runaway process.

For processes that are consuming CPU in a tight loop and not responding to signals, check whether it is in an uninterruptible sleep state (D state in ps output). A process in D state is waiting for I/O — usually disk — and cannot be killed until the I/O request completes or times out. This is often a symptom of a stuck NFS mount or a failing disk rather than a software bug.

Process Priority: nice and renice

Before killing a high-CPU process, consider reducing its priority instead. The nice command starts a process with a lower scheduling priority. The renice command adjusts priority for a running process.

Nice values range from -20 (highest priority) to 19 (lowest). Regular users can only increase nice values (reduce priority). Only root can decrease nice values (increase priority):

nice -n 10 make -j4           # Start a build with reduced priority
sudo renice -n 15 -p 1234     # Reduce priority of running process 1234

Setting a backup or compilation job to nice 15 lets it use available CPU without competing with interactive applications, eliminating the need to kill it while it is still doing useful work.

Building a reliable backup strategy that runs at appropriate nice levels is a core part of server maintenance — the complete Linux server backup guide covers scheduling, prioritization, and storage options for production server backups.

Using top and ps Together Effectively

The practical workflow for handling a misbehaving system:

1. Run top to identify which process is consuming resources
2. Note the PID and command name
3. Use ps aux | grep [name] to see all instances
4. Check /proc/[PID]/cmdline to confirm what the process is
5. Send SIGTERM first: kill [PID]
6. Wait 5–10 seconds — check if the process exited with ps aux | grep [PID]
7. If still running, send SIGKILL: kill -9 [PID]
8. Investigate the cause to prevent recurrence

Processes that regularly need to be killed indicate an underlying problem: a memory leak, an unhandled exception loop, or a misconfigured service. The kill command solves the immediate symptom. Understanding why the process became problematic prevents it from recurring.