VMware ESXi and vSphere Cluster Management

Kill a Process by Name in Linux with killall

Learn how to safely stop Linux processes by executable name with killall, choose signals, verify results, avoid accidental matches, and use systemctl or pkill when appropriate.

A process is an executing instance of a program. Every running process has a numeric process ID (PID) and a process name, usually derived from its executable. Linux lets you signal a process by PID with kill, or select processes by name with killall.

This guide focuses on killall. For related process-management techniques, see Linux process termination by name.

What killall does

killall sends a signal—a notification requesting an action—to processes whose names match the supplied name. The important consequence is that one command can affect every matching process, not just one instance.

For example, three running instances may all have the process name worker. Running killall worker can request termination of all three. A process name is not necessarily the same as the full command line, arguments, window title, or arbitrary text shown by a process viewer.

On Linux systems that use the common psmisc implementation, matching normally applies to the executable or process name. Check your local implementation with killall --help and man killall.

Basic syntax

killall [options] process_name

When no signal option is supplied, killall sends SIGTERM. SIGTERM is the normal graceful-stop request: an application may handle it, close files, save state, and clean up before exiting.

killall worker

Use a harmless sample name such as worker only when that is the actual process you intend to stop. Always verify the name and the matching instances before running the command.

Inspect before signaling

pgrep -a worker
pidof worker
ps -ef | grep '[w]orker'

pgrep -a is often the clearest option because it displays matching PIDs and command lines. ps lists process information, while pidof reports PIDs associated with a program name. Check the owner as well as the command line.

Choosing a signal

Use -s to select a signal. Implementations commonly accept both named and numeric forms:

killall -s TERM worker
killall -s KILL worker
killall -s 9 worker

Signal — Number — Meaning — When to use — Can the process handle it?

SIGTERM — 15 — Normal termination request — First choice for a graceful shutdown — Usually yes

SIGKILL — 9 — Immediate force-stop — Last resort when SIGTERM fails — No

SIGHUP — 1 — Often requests configuration reload — Only when the application documents this behavior — Usually yes

SIGINT — 2 — Interrupt request, similar to terminal interruption — Programs that specifically use it for cancellation — Usually yes

SIGTERM: the normal first step

killall -s TERM worker

SIGTERM gives the program an opportunity to finish or clean up. The process may not disappear immediately; it can take time to close resources and exit. Verify its status after waiting briefly.

SIGKILL: a last resort

killall -s KILL worker
killall -s 9 worker

SIGKILL cannot be caught, blocked, or handled by the target process. The kernel stops the process without allowing normal cleanup. This can leave incomplete work, partially written files, locks, or temporary files. Use it only after confirming that a graceful SIGTERM did not work and that interrupting the workload is acceptable.

Example: stopping every dd process

killall -s 9 dd

Danger: this targets every process named dd. It can interrupt disk imaging, backups, data copies, or other storage operations and may damage the resulting data. Inspect all matches first, try killall -s TERM dd, and use signal 9 only when you understand the consequences.

Verify the result

pgrep -a worker
ps -ef | grep '[w]orker'

If these commands return no matching process, the process has exited. If a process remains after SIGTERM, it may still be performing shutdown work, may be blocked, or may be automatically restarted by a supervisor. Do not immediately assume that repeated force-killing is the right solution.

killall -w worker

On implementations that support -w, this waits for matching processes to exit. Check the local manual because waiting behavior and supported options differ.

Options that improve safety

Option — Purpose — Example — Availability

-s — Select a named or numeric signal — killall -s TERM worker — Common, but confirm locally

-i — Ask for confirmation for each match — killall -i worker — Supported by common Linux implementations

-v — Report which processes were successfully signaled — killall -v worker — Supported by common Linux implementations

-w — Wait for matching processes to terminate — killall -w worker — Implementation dependent

-e or an exact-match option — Avoid broader name matches — killall -e worker — Check killall --help; option names vary

Interactive confirmation is useful when several instances exist:

killall -i worker

Some Linux implementations also provide age-based selection, such as options that select processes older or younger than a duration. These options are implementation-specific; read man killall before using them. Age filters do not replace inspecting the actual targets.

Permissions and sudo

Ordinary users can generally signal only processes they own. A process owned by another user or by root may require authorized elevated privileges:

sudo killall worker

Use sudo only when necessary and when you understand every matching process. Broadly killing system processes can terminate essential components, disrupt other users, or cause a service manager to restart the program.

When killall is not the best tool

Command — Selection method — Typical use — Primary safety concern

kill — One or more known PIDs — Stop a specific process — A wrong PID can affect an unrelated process

killall — Executable or process name — Stop all matching instances — Shared names can terminate more processes than intended

pkill — Name, pattern, command line, or other attributes — Select processes using more detailed criteria — Patterns can match unexpectedly

systemctl stop — A systemd service unit — Stop a managed Linux service — The unit name must be identified correctly

Use systemctl for managed services

If a process belongs to a systemd service, the service manager usually knows how to stop its child processes, update service state, and apply restart policies. Prefer:

sudo systemctl stop service_name

A process killed with killall may immediately return if systemd or another supervisor is configured to restart it.

Use pkill for richer matching

pkill also sends signals to selected processes, but it can match process names and, with suitable options, full command lines or other attributes. Use its manual page and carefully test patterns before signaling. Name-based matching with killall is often easier to understand when the executable name is exact and known.

Use kill for one specific instance

If inspection shows that only one PID should stop, use kill rather than affecting every process with the same name:

kill 12345
kill -KILL 12345

As with killall, use a graceful signal first and reserve SIGKILL for a confirmed last resort.

What about xkill?

xkill is a graphical-session utility for closing an unresponsive GUI window. It is not a general replacement for selecting Linux processes by executable name.

Troubleshooting

No process was killed

The supplied name may not match the executable name.
The visible command line may differ from the process name.
The process may belong to another user.
The process may already have exited.

Use pgrep -a, ps, or pidof to find the exact name and owner. Use sudo only when authorized. If you need command-line matching, consider carefully chosen pkill options.

The process remains after killall

It may still be handling SIGTERM.
It may be blocked or unresponsive.
A service manager or supervisor may have restarted it.

Wait and check with pgrep. If systemd manages it, stop the service with systemctl. Escalate to SIGKILL only after evaluating data-loss and cleanup risks.

Too many processes were terminated

Several instances may share one process name, or the local matching rules may be broader than expected. Inspect with pgrep -a, use -i or an exact-name option where supported, and use individual PIDs with kill when only selected instances should stop.

Permission denied

Confirm ownership with ps. If the target belongs to another account or root, use authorized elevated access or ask an administrator. For a managed service, prefer its service manager.

The process returns immediately

A supervisor, cron job, container runtime, or systemd restart policy may be relaunching it. Identify the parent supervisor or service unit and stop the responsible workload through that management tool instead of repeatedly running killall.

Portability notes

killall behavior differs among Unix-like systems. Linux commonly uses the psmisc implementation, but supported options, matching rules, and even the meaning of the command can differ on non-Linux systems. Do not assume Linux-specific instructions are portable. Run killall --help and read man killall on the machine you are administering.

Safe workflow

Identify the executable name and inspect all matching processes with pgrep -a, ps, or pidof.
Confirm that every match can safely be stopped.
If the process is a systemd service, prefer sudo systemctl stop service_name.
Otherwise, send SIGTERM with killall process_name or killall -s TERM process_name.
Wait briefly and verify with pgrep.
Use -i, -v, -w, or an exact-match option when supported and useful.
Use SIGKILL only when the process remains and forceful termination is justified.