4 ms·
When I was taking an operating systems class I wrote a fork bomb to play with: ~ $ gcc fork-bomb.c ~ $ ./a.out I saw that it did indeed crash my lab m
by jefftk 7y ago
When I was taking an operating systems class I wrote a fork bomb to play with:
~ $ gcc fork-bomb.c
~ $ ./a.out
I saw that it did indeed crash my lab machine, and when it rebooted I went on with my life.
Our CS lab had a central server which served a lot of important functions and also was the terminal server you could SSH into when working from your dorm. All of these had shared home directories.
Late one night working from my dorm before a big project was due I ran:
project $ gcc project.c
project $ ~/a.out # note the '~'
And forkbombed the central server. A lot of people were pretty mad at me.
Lessons learned:
* People should not be logging into the central server to do their work, or it should at least have nproc limits
* Always name your executables (gcc foo.c -o foo)
* Don't leave bombs lying around
- gizmo385 7y ago> Don't leave bombs lying around I'd say that's probably good advice regardless of your profession ;)
- btilly 7y ago...or it should at least have nproc limits I believe that nproc limits are only useful against accidents. In particular the following shell script is very good at taking out systems no matter what limits you set. #!/bin/sh perl -e '1 while push @big, 1` & $0 & $0 If you prevent it from taking out all of the process spots, it still is going to wipe out your memory. If you set paranoid enough limits on both memory and process spots, the system is going to be unusable for normal use cases.