How to Kill a Process in Linux

To kill a process in Linux, identify the exact process first, send a graceful termination signal, then force it only if it refuses to stop. That order matters on a VPS because the wrong target can interrupt SSH, a database worker, a queue consumer, or a web service with active requests.

This tutorial shows a safe workflow: confirm the PID, understand signals, use PID-based commands first, use name-based commands only when the match is precise, and treat force killing as the last step.

In the Ubuntu 24.04 disposable verification container used for this guide, pgrep, pkill, process-status output, and top were present, while killall was not present until the related package is installed. That is why this guide treats killall as a useful Linux tool, but not the first command to rely on across every minimal server image.

Key takeaways

• Start by confirming the process identity, not just the process name.
• Prefer TERM before KILL so the program has a chance to exit cleanly.
• Use PID targeting when you need the narrowest possible action.
• Use pgrep before pkill so you can see what a name pattern matches.
• Use killall carefully because it targets processes by command name and may not be installed on minimal systems.
• For related server administration context, see the Virtarix guides to Linux command line habits, VPS security basics, and server operating systems for VPS hosting.

Before you kill anything: identify the process

A process is a running program instance. The safe question is not “what command can stop it?” The safe question is “which exact process do I intend to stop?”

On a busy server, several processes can share a similar name. A web stack may have a parent process, worker processes, helper scripts, and cron-triggered jobs. Killing the wrong one can drop active requests or cause a supervisor to restart it immediately.

Use the PID when precision matters. Use the process name only when you know the match is exact or when you intentionally want to stop every matching worker.

A good check includes four details:

• PID: the process identifier you will target;
• parent PID: useful when a supervisor or shell started it;
• user: the account that owns the process;
• command: the executable and arguments that tell you what it is doing.

Understand Linux process signals

Linux process-stopping commands send signals. The two signals admins discuss most often are TERM and KILL.

TERM asks the process to terminate. A well-behaved program can catch it, close files, finish a transaction, release a lock, and exit. This is the correct first attempt for most processes.

KILL is different. It does not give the process the same chance to clean up. Use it when the process is stuck, when a graceful signal failed, and when you accept the risk of interrupting work.

That distinction matters for databases, web servers, queues, backup jobs, and anything writing files. If a process is managed by a service manager, container runtime, or process supervisor, killing the child process may not be the durable fix. It may simply restart.

Safe process-killing steps

Step 1: inspect the target PID

Use process-status output to inspect the PID before you signal it. Replace PID with the number you found from your process list.

ps -p PID -o pid,ppid,user,stat,comm,args

Read the output before continuing. If the command line, owner, or parent process does not match what you expected, stop and identify the process again.

This step is especially important over SSH. Do not kill your own shell, SSH session, package manager, database process, or web service just because its name looked familiar in a quick scan.

Step 2: try graceful termination by PID

Once the PID is confirmed, send TERM first.

kill -TERM PID

Wait a moment and check whether the process exited. For many tasks, this is enough. A clean exit is better than a forced exit because the process gets a chance to close its own resources.

If the process belongs to a production service, check the service health afterward. The command may have stopped the process correctly, but the application may still need a restart, a queue drain, or a supervisor-level action.

Step 3: force kill only after TERM fails

Use KILL only when the process is still running after a graceful attempt and you understand the risk.

kill -KILL PID

Do not paste this as the default command from memory. It is the escalation step. If the process is writing a database file, rotating logs, processing uploads, or running a backup, force killing can leave partial work behind.

A useful rule is: if you cannot explain what the process is and what it was doing, you are not ready to force kill it on a production VPS.

Step 4: find matching processes with pgrep

When the PID is not known, use pgrep to inspect matches by name before using a name-based kill command.

pgrep -a sleep

The -a output helps because it shows the matching command line, not just a bare PID list. Replace sleep with the process name you are investigating.

Be careful with partial names. A short pattern can match more than you meant. For exact process-name matching, use the exact-match option with pkill in the next step.

Step 5: kill by exact name with pkill

Use pkill when you intentionally want to signal every process matching a name pattern. For safer name matching, make the match exact.

pkill -TERM -x sleep

This sends TERM to processes whose name exactly matches sleep. On a real server, replace sleep with the process name you confirmed with pgrep.

Name-based killing is useful for duplicate workers or test processes. It is risky for broad patterns. For example, a vague pattern could match a parent and several children, or match a helper command you did not intend to stop.

What about killall?

killall is also a name-based process tool on Linux, but it should not be your first habit on a minimal VPS. Some images do not include it by default, and the name can create false confidence for admins who move between Unix-like systems.

Use it only when you have confirmed that the Linux implementation is available and that the command name is the exact group you want to signal. If you already have pgrep and pkill, those tools usually give you a clearer inspect-then-act workflow.

The safe mental model is simple: use pgrep to see matches, use PID-based kill for precision, and use name-based tools only when stopping every matching process is intentional.

Interactive termination with top

top is useful when you want to watch CPU or memory activity while deciding what to stop. It gives a live process view, which can be easier for beginners than switching between several commands.

top

Use it to identify the process and confirm whether it is still consuming resources. If you decide to stop something, keep the same safety rules: confirm the target, prefer graceful termination, and avoid force unless the process is stuck.

For production work, do not rely on visual ranking alone. A process at the top of the list may be busy for a legitimate reason, such as a backup, image conversion, package update, or database maintenance task.