How does this other version of the bash fork bomb work? How does this other version of the bash fork bomb work? bash bash

How does this other version of the bash fork bomb work?


If you break this bomb down a little it might make more sense. Change this to:

#!/bin/bash$0

This bomb will spawn a new copy of the shell script over and over again:

$ ps auxw | grep pts/2sarnold   2410  0.0  0.1  24840  6340 pts/2    Ss   Nov17   0:01 bashsarnold  17280  0.0  0.0  12296  1600 pts/2    S+   18:01   0:00 /bin/bash ./bomb.shsarnold  17281  0.0  0.0  12296  1600 pts/2    S+   18:01   0:00 /bin/bash ./bomb.shsarnold  17282  0.0  0.0  12296  1600 pts/2    S+   18:01   0:00 /bin/bash ./bomb.shsarnold  17283  0.0  0.0  12296  1596 pts/2    S+   18:01   0:00 /bin/bash ./bomb.shsarnold  17284  0.0  0.0  12296  1600 pts/2    S+   18:01   0:00 /bin/bash ./bomb.sh...$ ps auxw | grep pts/2 | wc -l2077

Each old one is essentially "dead" -- waiting to reap the exit status from the executed child. Of course, that won't happen until one of the executed children finally cannot execute due to process limits. (Which incidentally reminds me that perhaps setting an nproc rlimit would be a good idea before playing much further.)

So this process tree looks like this:

1 2  3   4    5     6

If you add the & to the end of the command, you'll see that older ones can eventually get scheduled and die. New ones form just as rapidly though, so this causes pretty significant churn and helps reduce the chance that it'll just end when the maximum number of processes have been spawned. The tree will look more like this:

1 2  3    5     6       8

Adding the second $0 & line will cause the tree to look a little different:

           1        2     3      4   5 6   7

Except it probably won't be this nice -- the second process might start the third, rather than the first one starting the third. It'll probably look mighty chaotic.

Each "layer" will double the size of the previous layer, on the whole, but execve(2) can only be called so often -- the trick is that this bomb will probably force far more process context switches than the simpler bombs, and all those TLB flushes are going to significantly impact the performance of the system. Because parents will be essentially randomly dying off after executing both children, init(8) will have far more processes re-parented. All this will increase the number of signals sent to init(8) to clean up, which would make it harder for an admin to log in and fix the problem.


When you run $0 &, Bash runs a new process in the background that runs this script. You start by doing it twice. Then each one of those scripts does it twice, so the second round of instances starts four instances. The next round starts eight, then 16, then 32, and so on.


$0 is a variable containing the very first part of the command that was used to call this script: The name and location of the script. If for example the command that you used to call the script is /home/user/bin/bomb foo bar, $0 will contain /home/user/bin/bomb. So $0 & means run this same script in the background. Since it is in the script twice, it will spawn 2 children. Each of the children will spawn 2 more children, and so on, exponentially.