In a slashdot signature I found the bash command:
I'm sure it's a fork-bomb, but is someone able to explain how it works?

Sorry, a Google search did help me already:
http://www.euglug.org/pipermail/eugl...st/004338.html

Certainly looks something like that. It is more intelligible once you recognize the function definition pattern:
The function name in question is ":". Inside the function it calls itself twice, connecting the stdout of the first instance to the stdin of the second instance. This keeps both running indefinitely. This pipeline is executed in the background, so the function can return. The ;: at the end terminates the function declaration and executes it.

So, because it's calling itself and returning without waiting for the child invocations to finish, you quickly end up with exponential growth of numbers of running instances of this function.

Exactly what happens when you get a lot of instances of this function isn't completely clear to me. As far as I understand it, they will all execute in the same shell process. So I would imagine you'd pin your CPU and either exhaust memory or fill up that shell's allocation of file handles. If the ulimits are set badly on your system (too many Linux distros don't set paranoid ulimits!), you might fill up the whole file tables in the kernel.

Perhaps someone would care to execute this on a test machine and report what it does (whether it creates lots of processes, or just one which swamps memory / pegs the CPU?).

Thanks. I actually understand this thing now.

Well since I have a pretty robust system which doesn't blink twice if you hit the powerswitch I tried it. After about 4 seconds I got
bash: fork: process temporarily unavailable
along with whirring of disks. Then more repititions of the message occasionally and continual whirring -probaly swap drive. But you'll never get any window to refresh or display after running this.
Perhaps doing a 'swapoff -a' first and then running this would serve as quick way to test OOM finctionality.
Don't try this unless you are using reiserfs or you might be very sorry...

Simple infinite recursion

I once tested a meaty sunos machine with a fork bomb. It was quite robust. Responsiveness dropped terribly, but I still had a shell which worked (very slowly). Most of the time I for "resource unavailable" messages but every so often I could run something. I managed to write a little loop which ran ps, iterated over the output and extracted the PIDs of the forking nasty and put them all to sleep using "kill -SIGSTOP". Then I killed them.

I believe that test included a bomb with a pipe in like this one. I suspect this makes the bomb less effective. If the user's process limit it hit with one process left before the limit, it can't "fill it up" totally because it needs two spare processes to start the pipeline.

What I don't understand is that if I write a shell function which prints the PID, it doesn't create a new process - there is no fork to speak of. Not with bash anyhow. Anyone know how hat happens - does it exhaust memory?

Lastly. How does one prevent a nasty little package like this killing your Linux box? How do you configure the limits? I know that in a shell you can use the ulimit command, but what about system-wide limits?

There might be some bash builtins. See 'help' for a nice list, or "man bash" or "man bashbuiltins".


I believe you can set this from 'pam', or /etc/profile so every user gets this. Still makes me wonder about non-login shells though.