Linux killall Command: How to Stop Processes by Name

Sometimes a program keeps running after its work is done, and you need to stop it without looking up a process ID. The PSmisc version of killall selects running programs by command name and sends them a signal, with SIGTERM as its default.

In this piece, I’ll show you how to check your installed implementation and choose a signal after inspecting matching processes.

TL;DR

Use killall to signal running processes by command name after checking the matches.

• Use killall NAME to send SIGTERM by default.
• Check pgrep -a NAME before acting.
• Reserve SIGKILL for a verified process that will not stop normally.
• Check the installed killall manual because implementations differ.

What Is the killall Command in Linux?

killall is a process-control utility that looks up running programs by command name. The PSmisc implementation sends SIGTERM by default, asking each selected program to end.

A process is a running program, and its process identifier, or PID, is a number assigned by the operating system. Both commands send signals, so the word “kill” does not mean that every call forcibly stops a program.

I checked killall --version and found PSmisc 23.7. Its options and matching rules are implementation-specific, so check man killall on the machine where you plan to use it.

For one known process, the kill command in Linux offers a PID-based alternative.

A signal is a notification sent to a process by the operating system or a user command. The process may handle some signals, while others have fixed behavior. The important choice with killall is therefore twofold: which processes match the name, and what signal should each matching process receive?

Names are convenient when a task concerns a group of identical program instances, such as several local copies of a tool. They can be ambiguous when unrelated processes share a name or when a wrapper launches a differently named executable. PID-based selection is more precise for one inspected process, while name selection is faster for a deliberately verified group.

How to Use the killall Command Step by Step

Use the following sequence to check the target before sending a signal. This keeps the command scope visible.

Step 1: Check which killall implementation is installed

Check the local help and version before relying on an option.

killall --version
killall --help

The help output lists the installed flags. In PSmisc, -s SIGNAL selects a signal and -v reports successful sends.

Step 2: Inspect processes that match the name

Use pgrep to list matching process IDs and command lines without sending a signal. Replace APP_NAME with a distinctive command name that appears in the process list.

pgrep -a APP_NAME

Review each listed command line and its owner. If pgrep returns no rows, confirm the executable name and whether your account can see the process.

Step 3: Send the default termination signal

When the process list confirms the target, use its command name with killall. SIGTERM gives a program an opportunity to handle shutdown.

killall APP_NAME

Replace APP_NAME with the command name you verified, and do not run this form until you have checked which processes it matches. If the command reports that no process was found, it may have exited already or its process name may differ from the executable name you expected.

Keep the command name narrow rather than using a fragment that appears in unrelated programs. A process can also exit between inspection and the signal request, so a no-match response can reflect a normal race rather than a syntax error. Re-run the read-only inspection before changing the target string.

Step 4: Choose a signal only when the default is insufficient

If the verified process remains active, SIGKILL is a last resort.

killall -s TERM APP_NAME
killall -s KILL APP_NAME

The first command requests normal termination. SIGKILL cannot be caught, so the process cannot run its own cleanup handler.

What Should You Check Before Using killall?

A command name can match several running instances, so use exact or constrained matching when the installed version supports it.

PSmisc can read truncated process names, and its manual documents a 15-character limit. Use -e for exact matching when the full command name matters.

With -e, killall skips entries whose names could not be read completely instead of treating a shortened name as a confirmed match. That behavior is useful when names share a prefix, but it also means a process may remain untouched. Check the output and the local manual before deciding whether a different selector is safer.

The -I option ignores case. Leave it out when capitalization distinguishes commands.

Case-insensitive matching broadens the set of possible targets. Before adding it, compare the names shown by pgrep and retain the case-sensitive default if it identifies the intended program without ambiguity.

The -r option treats a name as a POSIX extended regular expression, so characters such as a dot can change the match. Prefer a plain name when possible.

Use a regular expression only when its added flexibility solves a specific selection problem. A broad expression can select more than one executable, so inspect candidate processes first and avoid combining several broad filters unless you have checked how the installed implementation applies them.

The -u USER filter selects processes owned by that user. Include a command name to narrow it.

Ownership is a separate condition from the process name. A matching program owned by another account may not be signalable from your session, and adding a user filter does not grant permission to signal it. Check the owner before you choose a service-management route.

Use age filters with a clearly scoped name

The PSmisc implementation accepts -o TIME for processes older than a duration and -y TIME for processes younger than it. The duration combines a number with a unit such as seconds, minutes, hours or days.

These filters narrow the candidates by age, not by purpose or health. A process that has run for a long time is not necessarily stale, and a recently started process is not necessarily safe to stop. Pair a time condition with a distinctive name and verify the candidates before signaling.

killall -o 10m APP_NAME
killall -y 30s APP_NAME

The time filter changes which matching processes are selected. Consult the local manual for accepted units.

Age filters are useful for recurring programs when the start time helps distinguish a stale instance from a newly launched one. They are not a substitute for checking the command name: an old process can still be the wrong target. Use one filter at a time while learning the local syntax.

Wait for a signal result only when needed

Use -v to report a successful signal send, and add -w only when you need killall to wait for matching processes to disappear.

killall -v APP_NAME
killall -w APP_NAME

Use -w only when a script needs to wait for matching processes to disappear, since it may not return promptly if a process ignores the signal or remains as a zombie.

For a process that manages files or shared state, allow the program to finish its own shutdown path before considering escalation. If you use -w in a script, account for the possibility that it does not return promptly, and do not treat a verbose success message as proof that dependent work has completed.

Compare kill, killall and pkill by selector

Choose based on the selector you have. The procps pkill manual describes its own matching criteria and options.

For criteria beyond a command name, check the installed pkill manual before using an option copied from another distribution.

Choose a selector that fits the target. Use kill for one known PID, or killall for verified instances with one command name. Use pkill for other criteria supported by the installed procps options.

Use this check before retrying a failed command. It separates a naming problem from an ownership problem.

Check portability and permissions

The Linux PSmisc manual warns that other operating systems can give killall a different effect.

Do not copy a killall command between Linux and another Unix-like system without checking its manual. The same command name can refer to a different utility with different selection behavior. The version and help output identify which local documentation to consult.

id
killall --version
killall --help

A permission error means your account cannot signal the process. Check its owner with ps -o pid,user,comm -p PID, then use the documented service-management method if it belongs to another account or service.

Do not respond to a permission error by changing ownership or terminating a different process. First confirm the PID and owner still describe the process you intended. For a service, use its service manager so its configured stop behavior and dependent units are respected.

Run killall -l to list supported signals. SIGINT represents an interrupt and SIGHUP a hangup. Programs decide how to handle signals they can catch.

Signal names may be written with or without the SIG prefix in common command forms, but the local help is the authority for accepted spelling. A signal such as SIGHUP has program-specific effects, so do not assume it means the same thing as a normal termination request for every application.

Conclusion: Match Carefully, Then Signal

The PSmisc killall manual documents its flags and portability warning.

For PID-based targeting, see the Linux kill command guide. To inspect processes before acting, see how to use htop on Linux. The PSmisc killall manual page documents its options and limitations.

FAQ

These answers cover the signal and usage questions that commonly accompany process-name matching.