Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

user@host$ killall -9 -u user

Will it definitely kill all processes owned by user (including forkbombs)?

  1. No new processes is spawned to user from other users.
  2. No user's processes are in D-sleep and unkillable.
  3. No processes are trying to detect and ptrace or terminate this started killall (but they can ptrace or do other things with each other)
  4. There is ulimit that prevents too much processes (but killall is already started and allocated it's memory)

E.g. if killall will finish untampered and successfully is it 100% that no processes are left with this uid? If no, how to do it properly (with standard commands and no root access).

Will SysRq+I definitely kill all things (even replicating)?

share|improve this question
up vote 2 down vote accepted

No. killall first lists all processes that are to be killed, and then iterates through that list and kills them. If you have a forkbomb running, after killall will kill one of its processes, it is very likely that another process will immediately reclaim PID which has just freed, but killall thinks it already killed that process, so effectively nothing will happen.

You should use ulimit if a forkbomb is a problem for you. Limit number of processes to, for example, 128, and a forkbomb will silently die or stop expanding, depending on how it was written. Anyway, it will not present any danger to other users of that system.

share|improve this answer
ulimit is of course already in use for guest account. How to stop a forkbomb when it is running whithin ulimit (from the same account)? – Vi. Jun 15 '10 at 9:00
From the same account? How will you start a killall, if all pids are allocated to forkbomb? And if you can, first do killall -STOP -u user, thus preventing the bomb from propagation, and only then kill it with killall -9 -u user. – whitequark Jun 15 '10 at 10:58
Of course, if you really want to and can do that from the same account, you must somehow tell killall not to stop your shell (and self, probably). – whitequark Jun 15 '10 at 10:59
man killall: killall process never kills itself (but may kill other killall processes). – Vi. Jun 15 '10 at 21:18
@Vi: ah, that was pretty stupid. but the shell problem still arises. – whitequark Jun 16 '10 at 16:22

I recently had to deal with many forkbombs on a publicly accessible CTF server. I already had ulimits in place with pam_limits. For most forkbombs, you can do this:

killall -v -STOP -u mallory; killall -v -9 -u mallory

The STOP signal freezes the processes so killall has a chance to list them all and kill them.

But for typical python forkbombs, as soon as the ulimits are reached, the forking process will exit with an exception. This means that if your ulimit on nproc is 500, you will have a steady state of around 500 python processes, but each process will only be running for milliseconds at most. When I tried the above approach, by the time killall sent any given python process a signal, it had already exited.

The most important thing I learned came from killall(1):

   -g, --process-group
          Kill the process group to which the process  belongs.  The  kill
          signal  is  only sent once per group, even if multiple processes
          belonging to the same process group were found.

Thus, this will probably do what you want:

killall -9 -v -g -u mallory

Alternatively, you could do a killall -STOP instead and inspect the now quiescent processes and kill them at your leisure. You can use the CONT signal to resume them, if desired.

share|improve this answer
Stopping the processes before killing is good idea (as it prevents reclaiming resources and spawning new processes). Only need to be careful not to free one's own shell (we are cleaning up a forkbomb without root access) – Vi. Feb 25 '12 at 15:08

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.