On Apr 24, 2007, at 12:25 PM, <israel.garcia at cimex.com.cu> wrote: > Hi again, I was reading from the net > http://www.kriptopolis.org/node/4067 about a forkbomb and ran it > from a > root console in a non-critical machine running CentOS4.4 and the > serevr > goes down... the command I ran was :(){ :|:& };: > > Please, does anyone knows how to aboid this on CentOS? Easy: don't forkbomb your own system as root. First, understand that it didn't "go down". The system was working as designed. There's a limit to the number of processes that can be running, and you exhausted it. No new processes could start, so you couldn't log in again, or even use any functionality not built into the shell (ps, etc). Besides that, the load was quite high from many processes trying to fork as fast as they possibly could (even though all those fork() calls were failing with EAGAIN), so the system was slow. Since you were sitting at the shell that caused the problem, you could have hit ctrl-Z to suspend the first forkbomb subshell, then "kill -9 0" (a bash builtin) to kill the entire process group, and it would recover. Likewise if you happened to know the pid of the process group leader, "kill -9 -PID" would work. Or if you have a root shell running with a lot of builtin utilities (like BusyBox), you could use those to find the offending process group. Otherwise, you're screwed. It's possible to prevent unprivileged users from hogging all of the system resources (processes running, RAM, whatever) through the ulimit facility. But Linux (unlike other Unix systems) does not honor root's process limit. [1] Even if it did apply, hitting that artificially lower limit would still mean you couldn't fork() as root, so killing root processes would still be tricky - probably impossible without setup work. So basically, you can prevent unprivileged users from doing this but not root. That matches the Unix philosophy - root's supposed to know what he's doing: "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn Cheers, Scott [1] - <http://groups.google.com/group/mlist.linux.kernel/ browse_thread/thread/f771d3d01478babb>. More precisely, it's controlled by capability bits. In general, root has those bits set and other users don't. -- Scott Lamb <http://www.slamb.org/>