ubuntu freezes completely (all graphics and mouse) when executing shell ascii forkbomb

This honestly isn't a bug that Ubuntu becomes unstable/slow as you instruct it to open an infinite number of processes. We assume that when the user tells the computer to do something he means it. One should avoid typing in forkbombs into the terminal if one does not want to forkbomb his computer.

Yes, Ubunbu becoming slow is very much expected but it should be possible to "cancel" any mess and the machine should never freeze to the point when it's not possible to move the mouse.

To avoid that just
 * edit /etc/security/limits.conf
 * add a line like:
 * nproc MAX_PROCESS_COUNT

 where MAX_PROCESS_COUNT is a high number (i have 2000)
 Problem solved

As Alejandro said, yeah, you can set limits on the maximum process count.

To stall a forkbomb you first want to killall -STOP its associated processes, then killall them.

To avoid that just edit /etc/security/limits.conf and add a line like:
   "* nproc MAX_PROCESS_COUNT"

 where MAX_PROCESS_COUNT is a high number (i have 2000)
 Problem solved

PS my other post have way to many * to make sense

In addition, to safely restart your computer after a forkbomb has been initiated, you can hold ALT-SysRq and press R E I S U B with about 5 seconds in between each letter. This will safely unmount your filesystems before restarting, so you do not incur filesystem corruption.

I think it's fair to say that it's a problem that I can login to my shared web hosting company and run some command that makes the whole server unresponsive for several minutes. For this reason (and to avoid the laptop crash), I would like to see a change ubuntu default config here.

Maybe ubuntu devs feel that a default limit is bad for some reason? If so, one idea would be to allow the administrator to say "maximum X processes can be created every Y seconds", such a feature could be use to set a pretty non-intrusive default value that prevents crashes.

When one argues that "user should not do stupid things" one should look at the broad picture of how the industry has changed within the last decade or so. We now typically try to combat problems such as phishing using engineering counter measures (I won't comment on the pros/cons here, clearly some software gets it right and other doesn't).

If there was a command one could run as a non-admin on Vista (or such) to crash the whole box it would certainly not be dismissed as "user should not do that" kind of problem, no?

FWIW, I just tried it on Vista and W2K. On the latter I was able to recover just fine although it took 2-3 minutes before all my programs were swapped back into RAM. On the former taskmgr.exe just crashed so I could not get the fork bomb to stop but on Vista it can run the fork bomb for 10 minutes and the mouse never stops working nor does the display freeze.

This might also be useful:
http://en.wikipedia.org/wiki/Fork_bomb

On Fri, Nov 16, 2007 at 10:39:46PM -0000, mnemo wrote:
> Maybe ubuntu devs feel that a default limit is bad for some reason? If
> so, one idea would be to allow the administrator to say "maximum X
> processes can be created every Y seconds", such a feature could be use
> to set a pretty non-intrusive default value that prevents crashes.
This is already doable (see limits.conf suggestions above) and server
administrators should be familiar with these settings.

> If there was a command one could run as a non-admin on Vista (or such)
> to crash the whole box it would certainly not be dismissed as "user
> should not do that" kind of problem, no?
There certainly are identical denial-of-service exploits on all
platforms. You can forkbomb under Windows (in fact it succumbs to
nonresponse faster than Linux does) and do insane amounts of memory
allocation, hold half-open connections, and so on.

It is the job of the server administrator to set reasonable limits on
resources based on the usage pattern of his users to avoid these kinds
of problems.

I knew about limits.conf before I even posted this bug. The bug is only about the default values that ubuntu ships with nothing else. I believe Ubuntu should ship with a secure and stable configuration by default.

* Saying that "all other platforms crash" is bad argument (try "Windows boots slow so it's okay for Linux too" etc etc).
* The statement that "Windows succumbs to nonresponse faster than Linux" is wrong. I've been running a fork bomb on Vista since I posted the comment that starts with FWIW above it the Vista machine is still fork bomb and I can still move the mouse and I still see graphics updates every few seconds (even though the system is non-usable of course).
* I've not yet seen a single rational argument for *not* setting a secure and stable default value?
* Saying that "it's the job of the admin" is of course partly true but that doesn't in any way exclude having a smart default value.

You can see plenty of good arguments around this issue in this old thread:
http://forums.gentoo.org/viewtopic-t-309944.html

The difference I see in fork bombing between ubuntu and vista is that; in ubuntu a user space process can get the kernel to freeze so that mouse can't be moved and graphics updates stop. On Vista I don't see this (I encourage you to try it), the machine just runs and runs the mouse cursor movement doesn't even get sluggish (the user spaces processes does not succeed in hosing the Vista kernel).

That's my two cents..

This is a really good article as well:
http://www.securityfocus.com/columnists/308

The problem with 'sensible default', is that different systems handle different amount of load differently.
Ubuntu runs on systems from ~800mhz PC to 8 cored x32 threads (?) T2 Sparcs.

the limit that saves my (example) 800mhz pc will mean that the T2 is almost idle.

ps. I think the bug would have been better titled 'set maximum number of processes'. or similar.

Karl, I agree; that's a very good point. How about:

* Instead of setting a hard limit on the process count we can set a limit on the rate of increase?
* Or otherwise, expressing the maximum as a function of the hardware specs?

Also, at the end of the day even if we don't change the default values we can still try to fix the freeze. As I mentioned before Vista does not have a max count, but that doesn't mean that the fork bomb brings down the entire Vista kernel. On Ubuntu I see a complete freeze (can't even move mouse) and on Vista I just see massive slowdown (mouse it always movable and snappy though, and I can even open and close the start menu if I got some patience).