Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Wed, 10 Jul 2002 07:59:56 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: [PATCH] increase file descriptor limit automatically at httpd
	startup
In-reply-to: <m3y9cjn88v.fsf@rdu88-250-182.nc.rr.com>
To: dev@httpd.apache.org
Message-id: <1026313198.1437.11.camel@localhost>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <1026190072.1388.3.camel@localhost>
 <m3y9cjn88v.fsf@rdu88-250-182.nc.rr.com>

On Wed, 2002-07-10 at 04:16, Jeff Trawick wrote:
> Brian Pane <bpane@pacbell.net> writes:
> 
> > This patch increases the maximum number of open files
> > at httpd startup.  Before I commit, does anyone have a
> > scenario in which it won't be safe to do this?
> 
> devil's advocate comments:
> 
> 1) why write code to do something the user can easily take care of?

Mostly to avoid the converse devil's avocate question:
"Why make every user of the worker MPM write a wrapper script
to do something that the httpd can easily take care of?" :-)

> 2) shouldn't the user be able to control how many file descriptors
>    can be used by Apache?  in general, they should be able to mitigate
>    the resource growth caused by an Apache or module bug by playing
>    with soft limits
> 
>    a) this makes it harder to simulate running out of file descriptors
>       during testing
> 
>       without the patch, "ulimit -n 20" will generate some excitement;
>       with the patch, it is off to the OS documentation to figure out
>       how to change the hard limit on various systems

What do you think about about setting the ulimit in apachectl
(and not in the httpd) by default?

That would provide the intended benefit for normal users, but
developers doing testing of the out-of-files error handling could
easily comment out that line in apachectl.

--Brian