even if theyre running as root, if theres a getty running somewhere, you 
can still get in and fix it, if you're careful.. :) 
(or pop into the debugger and specifically start sending signals to 
them... :)

isildur

On Thu, 5 Dec 2002, Greg A. Woods wrote:

> [ On Wednesday, December 4, 2002 at 19:18:31 (-0800), Phil Nelson wrote: ]
> > Subject: Re: Fork bomb protection patch
> >
> >  On Wednesday, December 4, 2002 at 10:07:35 (+0100), Jaromir Dolecek wrote:
> > 
> > > Subject: Fork bomb protection patch
> > >
> > > * make process sleep for 0.5s if the system table is full
> > >   or when the user reaches their process number limit
> > >   - this is to not hog the system with huge number of CPU-hungry
> > >     looping processes
> > 
> > How about having this .5s sleep kick in only after a user has had 
> > a number of unsuccessful forks without a successful one.  This would still
> > stop the fork bomb, but let non-bombs that run at the process limit continue
> > without the .5s sleep.
> 
> Non of these "forced sleep" ideas will do anything to stop the fork bomb
> per se -- all they will do is reduce the amount of CPU such processes
> might consume and maybe, just maybe, allow a few of their already very
> few active pages to be paged out for a tiny amount of time.  But that
> doesn't really help in any significant way (other than save some
> operator who was trained in single-user system environment a few hairs
> while he or she frets about all the wrong things).
> 
> Such bad hacks are not necessary -- and they don't really solve anything.
> 
> All they do is add unnecessary complexity that can only get in the way.
> 
> Even if these processes are spinning in an idle CPU loop they cannot
> stop a proper timesharing system from allowing other authorised users
> from getting some work done.
> 
> What if one of those spinning processes is actually being run by the
> administrator in an attempt to find out what all the others are doing?
> 
> There is no possible generic way such a scheme can relibably
> discriminate between the good process(es) and the bad one(s) -- and no
> need or reason for it to do so either.
> 
> The best possible thing for the system to do is to simply cause the
> fork() call to return an error with EAGAIN and to continue to do the
> normal thing to ensure CPU hogs are only given their fair share of
> available cycles.
> 
> The last time I had to reset a *BSD system that was out of processes it
> was because the consumer was running as root and nothing could be done.
> Too damn much stuff runs as root.  The best fix is to stop running
> nearly everything as root, not to try to endow the kernel with psychic
> abilities such that it can out-guess even the administrator.
> 
> -- 
> 								Greg A. Woods
> 
> +1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
>