Earlier today when building something, I decided to run
$ make -j
perhaps out of habit with other programs such as
-j defaults to a reasonable limit.
About 20 seconds later, my entire desktop grinds to a halt. I look for various signs of activity. No fans spin up. The HDD light is a solid green, but I hear no disk activity. Hmmmmm. After 10 minutes of silence, I finally see a response to the first keypress I made ages ago, and I also begin to hear the all too familiar sound of disk thrashing. 20 minutes later of slowly trying to wade my way into a terminal on this unresponsive machine, I caved and used REISUB.
At first, I figured an unrelated desktop application must have been the culprit, because I have long since had memory limits placed on interactive bash sessions to prevent me from putting myself into exactly this sort of situation! But
/var/log/syslog tells a different story; the OOM killer left behind some
ps dumps which are suspiciously packed with
Here is a frequency analysis of one of those dumps:
Command Number of appearances 'sh' 322 'c++' 321 'cc1plus' 321 'chrome' 27 'make' 27 'bash' 3 all else combined 120
So I check the man page for GNU make: (emphasis added)
-j [jobs], --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.
I'm reluctant to see if I can reproduce the issue (Doctor, it hurts when I do this...), but the results of investigation so far seem to be a home run: Clearly,
make -j and the hundreds of resulting processes must have been the cause of the hang and the disk thrashing. That said, searching the internet, I can't find much warning against it. Am I jumping to conclusions?
make -j as dangerous as it would seem to me? If so, why on earth is it there, and what can be done to idiot-proof it?