--- Lord Isildur <mrfusion@uranium.vaxpower.org> wrote:
> but just denying the fork will also stop the fork bomb. 
> sure, itll use a lot of cpu. an admin can come by and kill them off, 
> though. the delay wont do anything that cant be done already, and
> adds 
> unneeded complexty and special cases into the mix. one would have to 
> check for this particular case (and keep state to check for it) on
> every 
> fork (or keep even more state to reduce the times one would need to
> check).
> if the quota on user processes is enforced, and a superuser can get 
> reserved slots to do what he needs, then he can stop and kill off the
> 
> offending suspects anyway. a daemon could also check for these
> conditions 
> from userland and, if it ran as root, do the stopping and killing
> too.
> 
> isildur

Would lowering the process priority of the offending process
temporarily be a good alternative to sleeping or is it all just a bad
idea? Would cpu hogs get lowered priorities anyway, making this
unneeded?

> 
> On Wed, 4 Dec 2002, Phil Nelson wrote:
> 
> >  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.
> > 
> > --Phil
> > 


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca