Hide Forgot
And I do mean pushed. Repeat by: 1. Have two swap paritions, both 127MB. 2. create /tmp/loop, containing: while :; do /tmp/loop ; done 3. Be in X-windows, with a loadaverage window open. (Yes, the idea of this was just to watch the exponential decay. It really is identical shape all the way down the tail, until the scaling factor gets in the way (when the indicated load-max goes to about 15-20, it stops being a perfect match). 4. As root, run /tmp/loop. 5. Hit ctrl-Z along the way when the system gets sluggish. 6. Resume it, and let it run until you get the message "fork failed -- resource temporarily unavailable". (Like I said, I pushed the kernel for this one) 7. Somewhere around here, a ctrl-C brought me back to a prompt, but did not kill all of the loops. One still ran. This step is not as clear from memory. 8. As soon as you realize that the load is still going up, "killall bash". 9. When you eventually get a prompt back, and the load starts dropping, there are a lot of mode S bash's still on the process chart. Swapfile space used (from /proc/meminfo) is over 121 MB. 10. kill the X server. 11. At the console: A lot of mode S (sleeping, waiting for something) bash's, with sequential process ID's. Occasional (every 60 seconds or so) messages from rpc_doio or rpc_send saying "sending evil packet" with a packet hex dump. 12. Try to kill one of those S mode bash's: get a stream of messages from the kernel about invalid swap file maps. swap_free: swap space map bad (entry 00xxxxxx) 13. Next step is to reboot, but not to try this a second time :-)
This fork bomb attack will probably succeed less well against a 2.2.x kernel than a 2.0.x kernel but yes, much more so with some hardware than other hardware, it is possible to get effects like this. I've marked this fixed because I think that the later kernel we released as part of 5.2 fixed some bugs that might be related to this, and because the 2.2.x kernels have many more improvements in the way the deal with swap. If you have users who are crashing machines like this, disabling their accounts is a good option; instituting process and cpu limits is another option if the first is not open to you. I hope that is useful information.