killall5 can signal almost every process on the machine at once, which is why it belongs in a shutdown script and not your everyday toolbox. This guide builds a safe way to assess a killall5 invocation, protect selected process IDs with -o, and understand exactly which processes the command can signal. The examples target killall5 from sysvinit-utils version 3.08-6ubuntu3 on this machine.
Safety boundary: sending a real signal is service-disrupting and normally needs elevated privileges, so this guide keeps that step behind an explicit warning. The command is primarily intended for the /etc/init.d scripts, not as a casual replacement for kill or pkill.
Start with ordinary, read-only checks. They show which binary and package you are reviewing:
$ command -v killall5
/usr/sbin/killall5
$ dpkg-query -W -f='${Package} ${Version}\n' sysvinit-utils
sysvinit-utils 3.08-6ubuntu3
The pathname and package version can differ on another distribution. Keep the local manpage beside your shell when reviewing a script, because killall5 has a deliberately narrow interface: a numeric signal, followed optionally by one or more -o options.
Checkpoint: confirm you are reviewing killall5, not a similarly named command from another package. It is also the target of the installed /usr/bin/pidof symbolic link, but that compatibility entry point has a different purpose and is outside this guide.
killall5 sends the chosen signal to all processes except kernel threads and processes in its own session. Excluding its own session stops a shell running an init script from being killed along with the other processes. This is a broad process-set operation, not a name match, and that distinction matters more here than almost anywhere else in this guide.
That boundary does not mean the command is harmless. A service, login session or supervising process outside the command's session can still receive the signal. The usual context is a SysV rc script where the surrounding shutdown or reboot operation has already established the required process set.
Inspect your current shell without changing state:
$ ps -o pid,ppid,sid,comm -p "$$"
PID PPID SID COMMAND
12345 12000 12345 bash
The numbers above are examples. The session ID is useful context, but it is not a complete preview of every process that would be selected. Do not treat a quick ps listing as a safety proof for a production invocation.
The -o option excludes a process by numeric PID. The manual accepts a comma-separated list, and the option can be repeated:
# Example only: replace these with PIDs you have verified
sudo /usr/sbin/killall5 -15 -o 12345,12346 -o 12347
The command above is intentionally not a copy-and-paste action.
Warning: signal 15 is SIGTERM, which asks processes to exit and can still stop services, interrupt jobs and cause data loss when an application does not finish cleanly. Never leave the example PIDs in a real script. Record the exact PIDs immediately before the operation and confirm what owns each one.
Use a read-only check for each candidate:
$ ps -o pid,ppid,sid,user,comm,args -p 12345,12346,12347
PID PPID SID USER COMMAND COMMAND
12345 12000 12345 alice example example --flag
If a protected process forks or exits, its PID may no longer describe the same program when the signal is sent. For a production shutdown, prefer the established init script and its service-specific stop logic. A static omit list is not a substitute for that lifecycle handling.
The signal is written as a number with a leading hyphen. The manpage documents the numeric form, so do not substitute a name such as -TERM unless the local command documentation explicitly supports it:
# Review only: do not run against an unverified host
sudo /usr/sbin/killall5 -15 -o 12345
For a controlled stop, 15 is the conventional first request.
Destructive action: a later escalation to signal 9, SIGKILL, is destructive to application cleanup and is not something to add as a routine second command. Stop and investigate processes that do not exit rather than turning a broad operation into an automatic kill sequence.
The command has no dry-run option in this manpage. A signal-zero experiment is not a dependable preview: permission checks, process races and the command's exit status can make it unsuitable as evidence that a later signal will affect exactly the processes you expect.
Capture the status immediately after the command. The documented results are:
/proc.$ sudo /usr/sbin/killall5 -15 -o 12345
$ status=$?
$ printf 'killall5 status: %s\n' "$status"
killall5 status: 0
The displayed status is illustrative. A zero status does not prove every intended service stopped, nor does a non-zero status identify which individual process remained. Check the service manager, process table and application logs using the host's normal shutdown procedure.
If /proc is unavailable, fix the host's process-information problem before attempting a broad signal. Adding sudo may resolve a permission failure, but it does not repair a missing mount or make an unsafe process selection safe.
Recovery: there is no general undo for a signal. A terminated process can only be restored by its normal supervisor, service restart procedure or a system recovery plan. If a service was stopped, use its documented init script or service manager command after checking dependencies:
$ sudo service SERVICE_NAME status
$ sudo service SERVICE_NAME start
Replace SERVICE_NAME with a real service name. Do not restart an unknown process merely because it disappeared. First identify what received the signal, check for unfinished writes or locks, and confirm the service is safe to start again. If the operation was part of a shutdown script, restore the previous script from version control or backup instead of improvising a reverse command.
sysvinit-utils version and binary path.killall5 in the init-script context it was designed for, rather than as an unreviewed interactive shortcut.