Stop the Right Linux Processes with killall

You will finish with 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. These examples use killall from PSmisc 23.7, installed here as package psmisc 23.7-1build1.

Allow 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 have different behaviour, so read that system's manual before using a privileged command.

Checkpoint: if command -v points somewhere unexpected, stop and inspect that executable before continuing.

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 because 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 that at least one process matched and the check succeeded. A non-zero status means that no suitable process was handled, or that an error occurred. It is a check, not proof that the eventual SIGTERM will make a process exit.

--exact requests an exact match. 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 that 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

There is no general undo for a signal. A process that exits must be restarted using its normal service or application procedure. If the target is a service, check its logs and use its documented start command rather than guessing.

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 that HUP reloads configuration. The program decides what each signal means. KILL is more disruptive: it cannot be caught or cleaned up, so use it only when a documented recovery procedure requires it. A stronger signal is not an undo for a mistaken match.

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. To select processes owned by one user:

$ killall --user APP_USER --exact SERVICE_NAME

The --user filter selects only processes owned by that user. Ordinary users can normally signal only their own processes. An administrator can signal more processes, which makes a mistaken name more damaging, not safer.

To act only on processes younger or older than a duration, use 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 --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 when the result is correct. Be precise with M and m: they are months and minutes respectively.

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.