I occasionally use the killall command to kill processes. The reason why I say ocassionally is that in some cases it hasn't worked for me.

A recent example was with thunderbird where there were about 5 instances in memory so I decided to use the killall command. It killed 2 processes and 3 were still left in memory. Tried again and the 3 were still there.

So I manually used the kill -9 command to kill each of the individual processes via their pids. That worked.

I mostly use the kill -9 command as it works. The killall command has let me down so many times I just don't bother using it. But there must be a reason why it doesn't work. Am I using it wrong?

I know there are other commands like pkill but I would be grateful to understand why the killall command doesn't work as expected. I have even tried to kill just one process and it is a hit and miss affair. But the kill -9 command works every time.

Any ideas?

PS: sudo doesn't make a difference

3 Answers 3


From the man page for killall

killall sends a signal to all processes running any of the specified commands. If no signal name is specified, SIGTERM is sent.

When you do a kill -9, you are sending the SIGKILL signal. If you want to send a SIGKILL with killall, you need to do


A good explanation of the difference between SIGKILL and SIGTERM (and why you should try SIGTERM first)

From http://rackerhacker.com/2010/03/18/sigterm-vs-sigkill/

Sending signals to processes using kill on a Unix system is not a new topic for most systems administrators, but I’ve been asked many times about the difference between kill and kill -9.

Anytime you use kill on a process, you’re actually sending the process a signal (in almost all situations – I’ll get into that soon). Standard C applications have a header file that contains the steps that the process should follow if it receives a particular signal. You can get an entire list of the available signals on your system by checking the man page for kill.

Consider a command like this:

kill 2563

This would send a signal called SIGTERM to the process. Once the process receives the notice, a few different things can happen:

  • the process may stop immediately
  • the process may stop after a short delay after cleaning up resources
  • the process may keep running indefinitely

The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.

Most system administrators will usually resort to the more abrupt signal when an application doesn’t respond to a SIGTERM:

kill -9 2563

The -9 tells the kill command that you want to send signal #9, which is called SIGKILL. With a name like that, it’s obvious that this signal carries a little more weight.

Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn’t even made aware of the SIGKILL signal since the signal goes straight to the kernel init. At that point, init will stop the process. The process never gets the opportunity to catch the signal and act on it.

However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won’t be able to stop it. Zombie processes and processes caught in an uninterruptible sleep cannot be stopped by the kernel, either. A reboot is required to clear those processes from the system.

When you sent killall (SIGTERM) to the thunderbird processes, you requested those processes to stop. Some of those processes weren't working correctly (probably why you needed to kill them in the first place), so they couldn't act on the SIGTERM signal.

  • Any speculation on why it only killed some of the thunderbird instances?
    – Meer Borg
    Mar 21, 2013 at 23:08
  • @Doogfar See my edited writeup (or the page I linked)
    – tgm4883
    Mar 21, 2013 at 23:09
  • Thanks, also explains why my Thunderbird corrupted, kill -9 was too harsh
    – Meer Borg
    Mar 21, 2013 at 23:14
  • 2
    Still doesn't work always. Jan 19, 2019 at 7:22

killall accepts most of the same syntax as kill. In particular, there's no need to write anything fancy to make killall do the equivalent of kill -9. This works just fine:

killall -9 thunderbird

(Of course, as discussed, you should usually be reluctant to use killall -9 or, equivalently, killall -KILL, unless other measures have already been tried without success.)

  • Still doesn't work always so there must be something else. Jan 19, 2019 at 7:22
  • Use: > sudo killall -s SIGTERM
    – Aries
    Feb 4, 2021 at 21:42

For those looking for a quick answer:

sudo killall -s SIGTERM processname
  • 1
    I think this is valuable, as sometimes a process can't be killed because it's owned by another user account; then running kill or killall as root with sudo can help. SIGTERM is the default signal so this works the same without -s SIGTERM, but including it does no harm. Although the OP mentions that sudo didn't help--and one doesn't usually run Thunderbird as another user--we don't know which commands were tried with sudo, and people sent here (by search engines or humans) may have a different problem. Feb 5, 2021 at 0:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .