I just learned about a fork bomb, an interesting type of a denial of service attack. Wikipedia (and a few other places) suggest using :(){ :|:& };: on UNIX machines to fork the process an infine number of times. However, it doesn't seem to work on Mac OS X Lion (I remember reading that the most popular operating systems are not vulnerable to such a direct attack). I am, however, very curious about how such an attack works (and looks), and would want to try it out my Mac. Is there a way to go around the system's safeguards, or is it the case that a fork bomb is not possible on Macs?

  • 2
    Note: I don't recommend trying fork bombs directly on your system (and never on someone else's system). Some OSes are still vulnerable. Try in a full VM (e.g. VirtualBox). Apr 23, 2012 at 23:32
  • Was this question answered(i.e. why fork bombs do not work on a Mac)? The accepted answer(that of Bruce Ediger) is merely explaining the functioning of a fork bomb and not necessarily speaking to the mechanics in OS X that are preventing a fork bomb from wreaking havoc(as it is wont to do elsewhere in Linux-land). Jan 21, 2014 at 22:51
  • @decimusphostle I am not sure how you came to a conclusion that my question was about why fork bombs don't work on Macs. So yes, the question was answered.
    – user13049
    Jan 22, 2014 at 12:51

4 Answers 4


How a fork bomb works: in C (or C-like) code, a function named fork() gets called. This causes linux or Unix or Unix-a-likes to create an entirely new process. This process has an address space, a process ID, a signal mask, open file descriptors, all manner of things that take up space in the OS kernel's somewhat limited memory. The newly created process also gets a spot in the kernel's data structure for processes to run. To the process that called fork(), it looks like nothing happened. A fork-bomb process will try to call fork() as fast as it can, as many times as it can.

The trick is that the newly created process also comes back from fork() in the same code. After a fork, you have two processes running the same code. Each new fork-bomb process tries to call fork() as fast as it can, as many times as it can. The code you've given as an example is a Bash-script version of a fork bomb.

Soon, all the OS kernel's process-related resources get used up. The process table is full. The waiting-to-run list of processes is full. Real memory is full, so paging starts. If this goes on long enough, the swap partition fills up.

What this looks like to a user: everything runs super slowly. You get error messages like "could not create process" when you try simple things like ls. Trying a ps causes an interminable pause (if it runs at all) and gives back a very long list of processes. Sometimes this situation requires a reboot via the power cord.

Fork bombs used to be called "rabbits" back in the old days. Because they reproduced so rapidly.

Just for fun, I wrote a fork bomb program in C:

#include <stdio.h>
#include <unistd.h>
main(int ac, char **av)
        while (1)

        return 0;

I compiled and ran that program under Arch Linux in one xterm. I another xterm I tried to get a process list:

1004 % ps -fu bediger
zsh: fork failed: resource temporarily unavailable

The Z shell in the 2nd xterm could not call fork() successfully as the fork bomb processes associated with the 1st xterm had used up all kernel resources related to process created and running.


There are many safeguards that can be put in place to prevent the fork bomb from working.

The simplest is:

ulimit -u 1024

limiting the number of user processes to 1024.

As far as going around the system safeguards there are certainly ways you can find of doing that but I don't think that anyone here will give you a way to do it but basically your system runs out of PIDs and can't spawn any more processes and basically grinds to a complete halt given that your bomb is taking 100% of the CPU trying to spawn more of itself.

  • Fork bombs have been around like for ever. This is indeed a very simple protection against fork bombs, but by far most of the Linux distributions do not implement it. Not sure why, but I think it has something to do with limiting trusted user processes too.
    – jippie
    Apr 23, 2012 at 19:33
  • @jippie Because it's better to do this in a different manner like rlimit
    – Karlson
    Apr 23, 2012 at 20:21
  • 4
    Still I think it is a foolish default that most distributions allow a fork bomb from unprivileged users to DoS a machine.
    – jippie
    Apr 23, 2012 at 20:56
  • 1
    @jippie The philosophy behind most Unix distributions is that they are run by "smart" people. So by default these "smart" people are allowed to do almost anything and the administrators will clamp down to make system more secure... I'll leave the conclusion to the reader's imagination. And file in question is /etc/security/limits.conf
    – Karlson
    Apr 23, 2012 at 21:00
  • 1
    Limiting the number of processes isn't always enough: the constant demand for forking overloads some schedulers (a scheduler that's not written with fork bomb prevention in mind might spend its time denying fork upon fork and almost never get around to scheduling the useful processes). Apr 23, 2012 at 23:30

If you're REALLY desperate to see how the fork bomb works, try running it, e.g. :(){ :|:& }, and then : but again, be warned. Tried it myself on Ubuntu. The system WILL FREEZE!

A simple dissection for you:

:() { #Define a new shell function
  :|:& #Pipe function named ':' through itself, creating two copies of itself, and make them run in the background
} #End of function definition block
;: #Call the ':' function. Note how the function is defined with two calls to itself piped through each other. This starts a chain reaction: those two copies will in turn create two more, and so on, ad infinitum

Be aware of this when attempting to do such harm.

  • 1
    this is just temporary and goes away on a reboot right?
    – Winnemucca
    Nov 10, 2017 at 20:59
  • 1
    @Winnemucca Well once the RAM and CPU are overloaded, system is frozen, just reboot and your machine will start normally, unless you set it as a startup script. That's not a very clever idea though.
    – Manchineel
    Dec 20, 2017 at 17:30

You can do this but make sure that the file is named file.py

import os 
while True

Then run it:

python file.py
  • 1
    Presumably, you want this to be run as a python script, right? Wouldn't you need a shebang for that? How can this run without making the file executable and adding a #!/usr/bin/python shebang?
    – terdon
    Dec 22, 2019 at 17:26
  • Also there is colon at end of True
    – mTvare
    Feb 12, 2021 at 9:25

You must log in to answer this question.