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.

Permissions and safety checks

You can generally signal processes you own. Stopping another user’s process or a system service may require elevated privileges, but do not add elevation automatically. First ask why your user does not own the process.

Before killing a process on a VPS, check:

• whether it is part of a service that should be stopped through the service manager;
• whether it belongs to a customer, website, database, or backup workflow;
• whether it is your active SSH session or a parent shell;
• whether a restart policy will bring it back immediately;
• whether a log file or monitoring alert explains why it is running.

If the process is managed by a service, the clean fix is usually to stop, restart, or reload the service through the manager. A direct kill is useful for emergencies and stuck processes, not as a replacement for service operations.

Troubleshooting: when the process comes back

If a process returns after you stop it, something else owns it. Common owners include a parent process, a process supervisor, a service manager, a container runtime, a cron job, or an application queue worker.

Do not keep killing the same child process repeatedly. Identify the manager and fix the source. Otherwise, you are treating the symptom and leaving the real behavior unchanged.

The same applies when a process refuses to die. It may be stuck in uninterruptible I/O, waiting on a filesystem, blocked by a device, or already becoming a zombie. In those cases, force killing may not solve the underlying problem immediately. You may need to investigate the parent process, disk state, or service health.

If you are practising Linux process management while building on a VPS, use a disposable test server before trying production services. Virtarix Cloud VPS plans give you a clean environment for learning these operational skills without risking a busy application host.

FAQ

Is force killing a Linux process safe?

Force killing can be necessary, but it should be the last step because the process does not get the same chance to close files, release locks, or finish active work.

Should I use kill, pkill, or killall?

Use kill with a PID for the narrowest target. Use pgrep plus pkill when you need a name-based workflow. Use killall only when it is available and you are certain the command name matches exactly what you want to stop.

Why does a process restart after I stop it?

A parent process, supervisor, service manager, container runtime, or scheduled job may be starting it again. The durable fix is to identify what manages the process, then change that manager’s configuration or state.

Summary

The safest way to kill a process in Linux is to identify the target precisely, choose the least disruptive stop method first, and escalate only when the process is confirmed stuck. PID-based kill is best for precision, pgrep plus pkill is useful for name-based workflows, and killall should be treated as optional rather than assumed on every minimal server.

On a production VPS, the command is only part of the job. The real skill is knowing what owns the process, what user impact the stop may cause, and how to verify the service afterward.

Byline: Peter French — Updated 2026-05-18.