Sign up ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

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.

share|improve this question

4 Answers 4

up vote 40 down vote accepted

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:

share|improve this answer
Hmm -- there was a killall on (old?) Solaris systems, but it behaved differently. It killed everything. – belacqua Feb 22 '11 at 8:18
@manish -- er, there was a different killall on SysV systems. – belacqua Feb 22 '11 at 8:56
@djeikyb The thought about killall being safer sounds right, or at least that could account for a lot of its popularity. – belacqua Feb 22 '11 at 8:59
@Manish: pkill (no kill) doesn't need the pid number, nor the process name. It does patter match on the process name. – Javier Rivera Feb 22 '11 at 9:35
killall is safer for users to blindly copy and paste, except if you're on a machine where killall does really kill all. It's unfortunate that the two different utilities come to have the same name. – Lie Ryan Mar 13 '13 at 4:28

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.

share|improve this answer
This is not true. killall without any arguments will do nothing, and killall will not ignore the arguments. kill -9 -1 might kill your system, and killall -9 -1 might as well. But not just killall [program] – Thomas W. Jul 30 '12 at 14:45
It's true on SysV systems, as now mentioned in the original question. – alanc Oct 16 '12 at 2:59

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

share|improve this answer
The same auto-completion will be done with pgrep/pkill. Something I commonly do is pkill plug<tab> to kill the flash plugin for firefox when I know that I don't have anything I want to use for a while but still want to actively use firefox. This is a function of the shell, not a difference between killall and pgrep/pkill. – Arcege Feb 22 '11 at 12:52
I didn't say is a difference - just a nice feature to avoid searching for PIDs, process names and etc. – jet Feb 22 '11 at 14:29

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.

share|improve this answer
No, neither pkill nor killall should be used in scripts, only interactively, and with caution. – geirha Feb 24 '11 at 10:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.