Warning
The objective of this guide is to
make you familiar with Linux Fork Bombing as well as prevention.
Experiment with this in your own box. Realize what a program can do
with self replication power. But don't misuse it. I am not liable for
such
application.
| Function which
eats CPU cycles |
"Recursive
call", "function
having recursive capability", "infinite loop" these are the very common
terminologies in the programming world. But these innocent tools have
deadly power to eat the complete system resources to make the system
completely unresponsive.
See the bash script below and don't
run it; it makes your system totally unresponsive if it is not
protected by anti-fork mechanism. Hardware restart is the only solution in that case.
chainreaction()
{
chainreaction|chainreaction&
};
chainreaction #
call the function |
The function forks itself forever, creating a huge number of
processes which will utilize every single cycle of the CPU,
causing the system to get stuck.
chainreaction|chainreaction calls itself and pipes the output
to another call of the function hence the function get called two times.
&(backgrounding)- There is no stop condition. Hence if the
function runs in foreground; calling function will not complete until
the call returns. So the calling function would wait forever and we
have the option to kill it and its children. But when running at
background the calling function is completed immediately and eat the
resources so quickly that the system becomes unresponsive.
Notice the recursive call is in the background hence the calling
process will "die" (in bash but not in C) as soon as it makes the
recursive call. If we call the function only once in the recursion,
we'll have always one process which will replace its parent, That's why
it is called twice here.
Make the above script as a one liner
chainreaction() { chainreaction|chainreaction& }; chainreaction
The following short Z Shell
code can destroy fork bomb in about a minute
while (sleep 100 &!) do;
done
The sleep is introduced to make processes sleep for a short period of time, and due to the delay there are less fork-bombs. Eventually the sleep processes fill up the process table themselves and the fork bombs die off.
Once the process table is full off sleep processes the while loop can be killed, and the sleep processes will die once their sleep time is up. Problem solved.
