After using just plain kill <some_pid>
on Unix systems for many years, I learned pkill
from a younger Linux-savvy co-worker colleague1.
I soon accepted the Linux-way,pgrep
-ing and pkill
-ing through many days and nights, through slow-downs and race conditions. This was all well and good.
But now I see nothing but killall
. How-to's seem to only mention killall
, and I'm not sure if this is some kind of parallel development, or if killall
is a successor to pkill
, or something else.
It seems to function as a more targeted pkill
, but I'm sure I'm missing something.
Can an Ubuntu/Debian-savvy2 person explain when (or why) killall
should be used, especially if it should be used in preference to pkill
(when pkill
often seems easier, because I can be sloppier with name matching, at least by default).
When speaking of killall
, I'm not thinking of the command that on some Unix systems (Solaris, AIX, ?) would kill all user processes. Here's a description of that version, from a manpage for IBM's AIX:
The killall command cancels all processes that you started, except those producing the killall process. This command provides a convenient means of canceling all processes created by the shell that you control. When started by a root user, the killall command cancels all cancellable processes except those processes that started it. If several Signals are specified, only the last one is effective.
1 'colleague' is free upgrade from 'co-worker', so might as well.
2 Originally I thought this was a Linux or Debian thing, but some sources are saying that the Linux killall
is derived from BSD-flavored Unix.
I think you see killall in how-to's because by default it requires the precise process name, whereas pkill does basic pattern matching. Thus, killall is safer for users to blindly copy and paste.
Pkill and killall both have distinguishing options. Killall has a flag to match by process age, pkill has a flag to only kill processes on a given tty. Etcetera ad nauseum. Neither is better, they just have different specialties.
I see from their man pages that killall comes from the psmisc package, which has several process managing utilities, but notably doesn't contain
ps
. It's the procps package that has ps, top, kill, and pkill (among others). I'd wager procps didn't originally have pkill, so psmisc scratched an itch and came up with killall.The pkill/pgrep man page says they were introduced in Solaris 7. As you mention, jgbelacqua, Solaris's killall was not the utility psmisc provides, thus Solaris probably only had the procps package. Someone wanted a pattern matching process tool, thus pkill and pgrep. Whether it was developed by the procps dev or added in afterwards, I don't know. Regardless, it made it in and became part of *nixes everywhere.
More sources:
Please be careful with "killall". On some systems (I forget which), killall kills all processes. It will silently ignore arguments and bring your system to a complete halt.
if you activate /etc/bash_completion, after
killall <part_of_process_name>
and hit tab - auto completes the process name from the list of running processesIf you look at the options on both programs, you'll see that they both do about the same thing, but in different ways.
pkill will perform matching on various attributes of a process (CMD, PID, PPID, UID...) and will send the given signal to each process that matches. (For CMD, a regular expression is used, for others it is a string). pkill is not interactive, but better for batch programs.
killall will perform matching on the process name (comm) or user (user), not on the whole command string. The argument is used as a simple string and must be match the entire 'comm' value (there is also a --regexp option to change this). killall has --interactive and --younger-than options, which pkill does not have.
There is also a killall5 is from SysV days and was ported to other UNIX variants (supposedly under the Ubuntu package 'sysutils'). This behaves differently in the old fashion manner. This was often used internally to the init scripts to shutdown or change to single-user mode.