#include <stdlib.h>
#include <unistd.h>

int main()

This is the code for a fork bomb.

In our college, we connect via telnet i.e client serving protocol. Some 100 systems are connected to server. Suddenly we saw the server becoming slow, and after some time it crashed. I came to know that sombody implemented a fork bomb.

How can we detect on which system the fork bomb is implemented? And how can we stop it?

One method is to limit the maximum number of processes that a single user may own. Is there any method to stop it and to know from which system it has been implemented?

  • 19
    Telnet? Seriously? You should really use SSH... – ThiefMaster Mar 16 '13 at 14:44
  • See also What's the best way to clean up after a fork bomb?. – Petr Mar 16 '13 at 19:25
  • See also unix.stackexchange.com/q/64611/17609 – moooeeeep Mar 16 '13 at 20:06
  • well it was migrated form SO but one answer could be at kernel level. some patches have been tentatively done but none seems to meet acceptance. My point is : how to detect it : well any uer will know it can't use system anymore, so detection point is perhaps not the key point. How to recover ? Current answer is reboot, i would state : a way to tell kernel to run only one process ( the one you want to clean up the mess ) and stop all others whathever they are. This could be a feature accessible only in system console. – philippe lhardy Mar 16 '13 at 20:12

One way is to limit the number of processes , a user can run.

Just login as root , and edit this file , to add users and configure , their limit.

# vi /etc/security/limits.conf

Add this line to the file

john hard nproc 10

Now user john can create only 10 processes.

  • I think you have to reboot to have the new settings in /etc/security/limits.conf take effect. – Dan D. Mar 17 '13 at 4:09
  • 2
    No. But they are applied by PAM so they only apply to new logins. – ThiefMaster Mar 17 '13 at 11:56

To stop a running fork bomb you might be able to use killall <name> to kill all processes of the bomb. However, since a fork bomb usually results in an incredibly high load on the system you might not be able to SSH into it or execute that. So a reboot might be necessary or at least much faster.

If every user has his own account on the system you can simply check everyone's home directory and search for the executable. Chances are good he also uploaded the source code so finding it shouldn't be too hard. If it was a shared account for all students you are out of luck. Especially after the telnet or ssh session of the user terminated you have no chance to find out who started it.

However, instead of punishing the user who detonated that fork bomb you should rather fix the system's configuration to disarm fork bombs. You can set per-user process limits using /etc/security/limits.conf and thus prevent a fork bomb from getting out of control - with e.g. just 50 processes a fork bomb won't do much damage.

  • its impossible to detect from which system its coming aa? – Rajesh M Mar 16 '13 at 15:24
  • @user1670364: It's not clear what you're asking. What do you mean by "its coming"? You can tell what user owns the process, what else do you want to know? – David Schwartz Mar 17 '13 at 3:32
  • @DavidSchwartz i mean its possible to detect the fork bomb on which system its being implemented? – Rajesh M Mar 17 '13 at 9:38
  • @user1670364: If you mean the system that's actually running the fork bomb, it's the one that's slow. If you mean the user that's responsible, it's the user who owns the processes that are forking. – David Schwartz Mar 17 '13 at 23:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.