After using just plain
kill <some_pid> on Unix systems for many years, I learned
pkill from a younger Linux-savvy
I soon accepted the Linux-way,
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 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.
Here is Solutions:
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.
- OpenSolaris (now Illumos) source code for ps, at launch in 2005
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 processes
If 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.
Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂