Quote:
Originally Posted by Fixit7
Does not work.
It is a shame, as the fork bomb would crash most Linux distros.
Windows has no defense, but I would think that Linux would. ??
|
:-)
Are you sure? What was the error message and what was recorded in the system logs?
What fork bombs will do is lock a USER. Not lock the system. When the users quota runs out the user is locked out. But a different user should be able to login and use the remaining resources.
The problem is determining what the resources should be. The default Linux limitations are based on a single user on a workstation. I have seen really large servers (512 CPUs, with 512GB of memory) brought to a deadlock by a fork bomb. Simple investigation showed that each user was allowed 74,000 processes...with an unlimited amount of stack space. The system only had 6GB of swap. So yes, it happens.
How to fix? Is not simple as it involves a number of different parameters:
how much memory is allowed per process (stack and heap mostly, but sometimes bss limits too).
how many processes at one time (remember, processes fork all the time, and that COULD lead to duplicating the memory allocation each time. The problem is forks don't usually duplicate all the memory. This part is called "over subscribing memory" and can deadlock the system too.)
How many users... and remember to include each of the system services running as a user too. If you don't, you tend to overestimate the amount of available memory.
How much swap space to have. After multiplying the number of allowed processes times the number of users, multiply by the amount of memory allocated... Now you know the absolute memory required without oversubscription. Deciding on how MUCH over subscription to allow is hard. It is usually guessed at. Multi-threaded applications don't duplicate memory, but they can surprise you because each thread gets a
separate stack, and that can grow really fast.
It is rather hard to lock a system with too many processes (even with a fork bomb) as what starts running out is the available memory+swap.
I have a dual quad, with 8GB of memory and 16GB swap - but I locked it up running Povray. Not by too many processes, but by using up all of main memory and most of swap.
Causing an out of memory lockup is SUPPOSED to be caught by the OOM signal. Unfortunately, it can't guarantee catching them (unless they are really really obvious). Things that use up memory slowly don't signal what is using too much memory - and the system can run out of memory and deadlock anyway. Paging activity takes time...and if all processes are page faulting at about the same rate, none show up as deserving to be aborted.
The other issue depends on the CPU. The active processes have to be handled by a CPU - so how many CPUS do you need for a given number of active processes... Allowing even 100 processes would overload a CPU, so a fork bomb with 100 processes would overload a CPU. It isn't a problem if you have 512 processors though.
General handling calls for a different method. Does the fork bomb impact a different user? This is one of the things that cgroups were created for, but to use them requires having more than one user. The only separation when there is only one, happens to separate system processes from that single user. The only way to actually test that is to attempt to login as a different user to the system that appears
overloaded. This alternate user will get a separate quota. You can think of it as the first user getting half of the system (not accurate, but it is a concept of what happens), the other half belongs to the system services. If the system services aren't using all of their 1/2, then the user gets whatever is left. When a different user logs in, then the new allocation will be 1/3 of the system, the system services are given 1/3, and the other user is cut to 1/3. If the other two users are using all of their quota, then the new user gets 1/3 + whatever the others aren't using...
So you get to check how (and what) the cgroup quota controls are configured to allow.