In message: <20021207015913.GG23325@bcd.geek.com.au>
            Daniel Carosone <dan@geek.com.au> writes:
: Time and real-world experience with the change are required, to
: investigate some of the theorising here and see where it really
: helps and hurts.  FreeBSD's experience seems to be positive so far,
: for starters..

My real-world experience with this hack in FreeBSD has ment the
difference between 'inexpereinced' programmers killing our main server
and merely making it a little slow until I killed their run-away
processes.  I'll be the first to admit that this isn't perfect, or you
can invent any number of ugly ways to use lots of CPU in pathological
ways.  However, you could do that before the patch as well.

Having done a lot of testing before that patch was committed on my
bouncer box, I saw that the fork bomb went from a terminal event for a
system due to local security policies to an easily correctable event.

There are a number of flaws in the arguments put forth against the
patch:

	1) A system on the edge will be tottered over: This is true
           only if it would have tottered over anyway.  The sleep
           makes it slower for those people doing forks, and gives
           more cpu time to those processes that aren't forking.  I'd
	   argue that that additional time would be a net positive
           since it rate limits what you can do when the system is on
           the point of collapse.  I can see the other side as well,
           so I'd say that this argument hinges on what people think a
           typical system on the edge would be.  Experience has shown
           that a system on the edge as described would be highly
           application dependent, so this change would help some folks
           and hurt others.

	2) Rampant forkers.  This will hurt them.  These beasts should
	   really have some better limiter in them than hitting the
	   wall.  Normal programs don't fork like a sob, so at worse
	   they have to wait 1/2s to find out the limits.

	3) But with the one slot, a sysadmin could regain the system.
           True, in theory, but in practice one slot is too few in a
           highly networked system.  Also, the days of the sysadmin
           necessarily knowing the root password to login as root on
           the console have passed to a large extent with many
           companies having the root password in the safe with no-one
           knowing it and all accss being done through sudo or a
           sudo-like thing.

I'd agree with Dan here.  It is a kudgel that's a big hint to the
scheduler to stay away from this process.  It is no different than
systrace saying 'hmmm, this program normally doesn't execute setuid
shells, so I think I'll deny it'.  In fact, one could write a policy
with systrace, I suspect, that might mitigate the effects of a fork
bomb (or not, to be honest, I don't know systrace at this point beyond
the high level descriptions that have floated around).

Keep it or not.  I think much of the reaction to this has been
emotionally driven rather than govnered by rational thought (myself
included).

It is different.  Better for some, worse for others and strange to many.

Warner