Advertisement

Fun with fork()

Started by February 23, 2004 02:04 PM
5 comments, last by BradDaBug 20 years, 6 months ago
I decided to see what would happen if I stuck fork() in an infinite loop. I mean, after all, it''s Linux, right? Nothing REALLY bad will happen, right? So I whipped up a quick program that did that and ran it. Pretty quickly my computer got REALLY slow. Then windows on the screen started disappearing. "Huh, that''s strange," I thought to myself. Finally they were all gone, and my screen went blank. Keyboard not responding. "That''s okay, I''ll just ssh into my machine and kill the forker." Tried it, didn''t work. My computer was completely unresponsive. So I had to reboot. I haven''t noticed any other problems except that Mozilla thinks there''s another mozilla running somewhere and I have to use an alternate profile. But considering I was running the forker as a regular user, shouldn''t there be some kind of protection to prevent some yahoo like me from killing a system like that? Game Development Wiki
I like the DARK layout!
Yup, fork-bombs are fun to write.

Process accounting and user quotas help prevent stuff like that. So does threatening to kick the ass of anyone who uses a fork-bomb on your box.

More fun to write than fork-bombs, tho, are sets of programs that cooperatively invoke each other when any of them are killed, such that it''s nearly impossible to kill them all.

"Sneftel is correct, if rather vulgar." --Flarelocke
Advertisement
Aahh yes, the rabbit problem....

It depends from system to system but if I remember properly /etc/security/limits.conf can be used to control this in linux. The problem is that a user and esp a server can run a lot of processes for legitimate reasons so the default this sort of stuff is usually turned off (i.e. unlimited).




[edited by - mauman on February 23, 2004 4:37:51 PM]
---CyberbrineDreamsSuspected implementation of the Windows idle loop: void idle_loop() { *((char*)rand()) = 0; }
Oh, and if you really wanna play with TEH SLOWNESS,
dd if=/dev/urandom of=/dev/null.

"Sneftel is correct, if rather vulgar." --Flarelocke
Sneftel - You have found a way to reduce the entropy of a closed system! Way to go, you are only a step away from making a perpetual motion machine!

BradDaBug - There's an option in ulimit for the maximum number of processes a user is allowed to create simultaneously.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)

[edited by - Fruny on February 23, 2004 5:00:40 PM]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Which kernel version were you running it on? The new scheduler in 2.6 could probably run an endless fork for even longer
-PoesRaven
Advertisement
ACtually the VM overcommit defaults in 2.6 will probably kill the processes quicker...

This topic is closed to new replies.

Advertisement