6

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)?

2 Answers 2

4

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.

5
  • 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.
    Commented Jun 15, 2010 at 9:00
  • 1
    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.
    – Catherine
    Commented Jun 15, 2010 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).
    – Catherine
    Commented Jun 15, 2010 at 10:59
  • 1
    man killall: killall process never kills itself (but may kill other killall processes).
    – Vi.
    Commented Jun 15, 2010 at 21:18
  • @Vi: ah, that was pretty stupid. but the shell problem still arises.
    – Catherine
    Commented Jun 16, 2010 at 16:22
1

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.

1
  • 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.
    Commented Feb 25, 2012 at 15:08

You must log in to answer this question.

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