Stop the Right Linux Processes with killall

killall stops every process matching a name in one go, which is exactly why a typo or a common name can hit far more than you meant. This guide builds a cautious way to stop processes by command name, verify the match before sending a real signal, and use filters when a plain name is too broad. The examples use killall from PSmisc 23.7, installed here as package psmisc 23.7-1build1.

• Time: about ten minutes.
• You need: a shell and a process you are allowed to inspect or stop. Most checks are ordinary commands; stopping another user's process, or a system service, normally needs elevated privileges and can disrupt work or availability.

1. Check which killall you have

Start by checking the executable and package version. This does not change any process:

$ command -v killall
/usr/bin/killall
$ killall --version
killall (PSmisc) 23.7
$ dpkg-query -W -f='${Package} ${Version}\n' psmisc
psmisc 23.7-1build1

The guide follows the installed killall(1) interface. On another Unix system, a command with the same name may behave differently, so read that system's manual before using a privileged command.

2. Understand the default before touching a process

killall NAME sends SIGTERM to every matching process. It matches the command name, not an arbitrary piece of the command line. The process running killall does not kill itself, although it can match another killall process.

That default is a real action, not a preview. Before using it, identify the candidate processes with pgrep or ps:

$ pgrep -a -x SERVICE_NAME
1234 /usr/local/bin/SERVICE_NAME
1278 /usr/local/bin/SERVICE_NAME

Replace SERVICE_NAME with the exact command name you have inspected. If the output contains an unrelated process, do not use a plain name. If it is a service, prefer the service manager's stop operation, since it records the intended unit and may handle dependencies.

Do not copy the example literally. A misspelled name can still match an unexpected program, and a common name such as python or java can cover several unrelated workloads.

3. Run a harmless match check

Use signal number zero to test whether matching processes are visible and signalable, without delivering a terminating signal:

$ killall --exact --quiet --signal 0 SERVICE_NAME
$ printf 'killall status: %s\n' "$?"
killall status: 0

Signal zero performs permission and existence checks without changing the target. A zero status means at least one process matched and the check succeeded. A non-zero status means no suitable process was handled, or an error occurred. It is a check, not proof that the eventual SIGTERM will make a process exit.

--exact requests an exact match, and it matters for long names because the kernel's short process name can be limited to 15 characters. Without --exact, killall may act on every process sharing the available prefix. With it, entries whose full name cannot be confirmed are skipped.

4. Stop one known process name

Only after the match check shows the intended targets should you send the default termination signal:

$ killall --exact SERVICE_NAME
$ printf 'killall status: %s\n' "$?"
killall status: 0

A zero status means at least one process was killed for each command name supplied. It does not mean every process has already exited: programs can catch or ignore SIGTERM and may need time to clean up.

Check the result using the same exact query:

$ pgrep -a -x SERVICE_NAME
$ printf 'pgrep status: %s\n' "$?"
pgrep status: 1

5. Choose a different signal deliberately

Use --signal when you have a specific reason. For example, HUP is commonly used by applications that document configuration reloads:

$ killall --exact --signal HUP SERVICE_NAME
$ printf 'signal status: %s\n' "$?"
signal status: 0

Do not assume HUP reloads configuration: the program decides what each signal means.

For a visible audit trail, add --verbose. For a prompt before each process, add --interactive:

$ killall --exact --interactive --signal TERM SERVICE_NAME
Kill SERVICE_NAME(1234) with signal 15? (y/N)

Interactive confirmation is useful at a terminal, but it is unsuitable for unattended jobs. Do not place a command that waits for input in a boot, monitoring or deployment script.

6. Narrow a broad match

If several processes share a name, use a filter rather than hoping the order is safe.

• By owner. Select processes owned by one user. Ordinary users can normally signal only their own processes; an administrator can signal more, which makes a mistaken name more damaging, not safer.
• By age. Act only on processes younger or older than a duration, using a number followed by a unit. The manual defines s, m, h, d, w, M and y for seconds, minutes, hours, days, weeks, months and years.

$ killall --user APP_USER --exact SERVICE_NAME

$ killall --exact --younger-than 5m SERVICE_NAME
$ killall --exact --older-than 2h SERVICE_NAME

These commands change state. First replace them with signal zero while checking the candidate set, then remove --signal 0 only once the result is correct. Be precise with M and m: they are months and minutes respectively, and that one is an easy way to have a very bad afternoon.

7. Know when waiting can hang

Add --wait when the next step must not start until the selected processes have disappeared:

$ killall --exact --wait SERVICE_NAME
$ printf 'killall status: %s\n' "$?"
killall status: 0

killall checks once per second. It can wait forever if the process ignores the signal, the signal has no effect, or the process remains as a zombie. It also cannot detect every case where a process disappears and another process takes the same PID between scans. Use a bounded external timeout when an unattended script must fail rather than wait indefinitely, and investigate before sending another signal.