On Sat, Dec 07, 2002 at 01:18:50AM +0100, Jaromir Dolecek wrote:
> 
> My guess that since fork-bombs normally don't happen, it simply
> wasn't important enough to adjust scheduler to handle stuff like
> this.

So, in order to have to "guess" about this, you'd have to have basically
zero experience ever running a large timesharing Unix system.  That, to
me, ought to raise a BIG RED FLAG in your mind that you might not really
understand the consequences of this change -- or the history of similar
efforts -- well enough to just blithely commit it after a day or so of
discussion.

Here's a clue for you: every fall, like clockwork, this problem rears
its head on basically every shared Unix system used to teach undergraduates
how to write simple Unix programs *in the world*.  If the solution you
propose didn't totally suck, believe me, given the academic history of
Berkeley Unix, it would be the default system behaviour by now.

The fact of the matter is that the simple, effective way to address this
problem is to appropriately set the resource limits -- both in terms of
number of processes and in terms of maximum CPU time per process -- for
normal users.  Once you do that, a quick two-step "SIGSTOP all miscreant
processes"/"SIGKILL them now that they're frozen in place" is sufficient
to allow you to move on to the next step in the algorithm, which is "Beat
student with stick" and, if necessary, "Beat student's professor/advisor 
with stick".

I'll tell you what: let's pick an arbiter who's got as much relevant
experience here as is available to us.  I've spent plenty of time
running Unix timesharing systems, but I'm already involved in the
debate.  If you come up with a solution that satisfies kre (after you
show him the rest of this discussion), I'll drop my objections.  Does that 
work for you?

Thor