Subject: Re: Fork bomb protection patch
To: Jaromir Dolecek <jdolecek@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 12/06/2002 12:56:55
[ On Friday, December 6, 2002 at 11:10:21 (+0100), Jaromir Dolecek wrote: ]
> Subject: Re: Fork bomb protection patch
>
> Roland Dowdeswell wrote:
> > and runs into its process limit. An example would be thttpd and
> > running CGI scripts. With the .5s sleep, if thttpd is asked to
> > run too many CGI scripts it will also mysteriously pause every once
> > in a while when serving up flat files---a situation which is both
> > counter-intuitive and suboptimal.
>
> The thttpd (IMO broken) behaviour
EXCUSE ME? thttpd does _exactly_ the right thing.
> Perhaps there is some disagreement on the purpose of user/system
> limits.
>
> IMHO the limits are there to ensure fair resource usage among users.
Yes, that's what they're there for.
> IMHO the thttpd behaviour is broken. It should really have some
> limit of 'maximum or running spawned children', rather than spawning
> unlimited number of childs to serve any incoming requests.
Huh?
The kernel _MUST_NOT_ penalize a process just because it has reached a
resource limit (unless it's the CPU-time hard limit in which case the
only choice is a hard uncatchable kill). The only correct response is
to return an error code indicating that the limit has been reached.
The limits are there to be bounced up against. Programs are supposed to
be checking for errors and understanding what the errors which indicate
resource limits mean in their context.
Why do you think user-land programs should have to go to all the trouble
and complexity of duplicating the resource utilization tracking already
done by the kernel?
> I think that as a general rule of thumb, a service shouldn't
> frequently run into it's resource limits during normal operation.
You're very VERY wrong about that. Especially about fork() -- this has
been the way things worked and were expected to work since before V7.
--
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>