You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2002/07/15 05:41:59 UTC
Re: cvs commit: httpd-2.0 CHANGES
I really don't like this. It adds unnecessary complexity to the configure
script, misleads admins in to thinking that they have to rerun configure
to set the file limit, and does something that should just be set by
the admin themselves at starttime.
-aaron
On Sun, Jul 14, 2002 at 11:18:46PM -0000, brianp@apache.org wrote:
> brianp 2002/07/14 16:18:46
>
> Modified: support config.m4 apachectl.in
> . CHANGES
> Log:
> Increase the per-process file descriptor limit in apachectl
> for the benefit of people running multithreaded MPMs or lots
> of vhosts
>
> Revision Changes Path
> 1.5 +6 -0 httpd-2.0/support/config.m4
>
> Index: config.m4
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/support/config.m4,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- config.m4 7 Feb 2002 23:01:47 -0000 1.4
> +++ config.m4 14 Jul 2002 23:18:45 -0000 1.5
> @@ -81,3 +81,9 @@
> ])
> APACHE_SUBST(checkgid_LTFLAGS)
>
> +if TMP_ULIMIT=`ulimit -H -n` && ulimit -S -n $TMP_ULIMIT ; then
> + APACHECTL_ULIMIT="ulimit -S -n \`ulimit -H -n\`"
> +else
> + APACHECTL_ULIMIT=""
> +fi
> +APACHE_SUBST(APACHECTL_ULIMIT)
>
>
>
> 1.14 +6 -0 httpd-2.0/support/apachectl.in
>
> Index: apachectl.in
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/support/apachectl.in,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -r1.13 -r1.14
> --- apachectl.in 27 May 2002 11:46:01 -0000 1.13
> +++ apachectl.in 14 Jul 2002 23:18:45 -0000 1.14
> @@ -44,8 +44,14 @@
> # have one, then status and fullstatus will not work.
> STATUSURL="http://localhost:@PORT@/server-status"
> #
> +# the command to increase the limit on open file descriptors
> +ULIMIT_MAX_FILES="@APACHECTL_ULIMIT@"
> # -------------------- --------------------
> # |||||||||||||||||||| END CONFIGURATION SECTION ||||||||||||||||||||
> +
> +if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
> + $ULIMIT_MAX_FILES
> +fi
>
> ERROR=0
> if [ "x$ARGV" = "x" ] ; then
>
>
>
> 1.864 +3 -0 httpd-2.0/CHANGES
>
> Index: CHANGES
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/CHANGES,v
> retrieving revision 1.863
> retrieving revision 1.864
> diff -u -r1.863 -r1.864
> --- CHANGES 13 Jul 2002 03:29:49 -0000 1.863
> +++ CHANGES 14 Jul 2002 23:18:45 -0000 1.864
> @@ -1,5 +1,8 @@
> Changes with Apache 2.0.40
>
> + *) Increase the limit on file descriptors per process in apachectl.
> + [Brian Pane]
> +
> *) Fix a dependency error when building ApacheMonitor, so that Win32
> and MSVC now trust that the project is current (when it is).
> [James Cox <im...@php.net>]
>
>
>
Re: cvs commit: httpd-2.0 CHANGES
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Jul 14, 2002 at 09:30:17PM -0700, Brian Pane wrote:
> Well, threaded MPMs or large vhost configurations won't run as
> shipped. And the httpd doesn't increase its own fd limit like
> competing servers do (or like 1.3 does, for that matter). And
> until this fix, the httpd wasn't operating in accordance with its
> own documentation, which claimed that the server would increase
> its own file descriptor limit as needed (second paragraph
> of http://httpd.apache.org/docs-2.0/vhosts/fd-limits.html )
I'm sorry, but may I'm misunderstanding what exactly it is that
you are trying to solve. Could you please elaborate on what it is
you've changed and what problems it solves (that can not be solved
by setting limits manually in a startup script)?
> >In order to use our product in certain ways your system may have
> >to be configured to allow our product to use more file descrioptors.
> >
> >Now you have made it so that the apachectl script overrides my
> >environment limits, this is badness.
>
> What's your use case for setting lower environmental limits?
To prevent the web server from using so many fds that other processes are
starved and/or fail. To prevent buggy modules from consuming more than
their fair share of valuable system resources. So that I as an admin
can simply set the limits that I prefer in my environment and not have
to undo some overrides that exist in a product-proprietary startup script.
-aaron
Re: cvs commit: httpd-2.0 CHANGES
Posted by Brian Pane <br...@apache.org>.
Aaron Bannert wrote:
>On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote:
>
>
>>It's
>>unreasonable to make the every admin responsible for hacking
>>their start scripts to work around our broken product.
>>
>>
>
>In what way is our product broken?
>
Well, threaded MPMs or large vhost configurations won't run as
shipped. And the httpd doesn't increase its own fd limit like
competing servers do (or like 1.3 does, for that matter). And
until this fix, the httpd wasn't operating in accordance with its
own documentation, which claimed that the server would increase
its own file descriptor limit as needed (second paragraph
of http://httpd.apache.org/docs-2.0/vhosts/fd-limits.html )
>In order to use our product in certain ways your system may have
>to be configured to allow our product to use more file descrioptors.
>
>Now you have made it so that the apachectl script overrides my
>environment limits, this is badness.
>
What's your use case for setting lower environmental limits?
--Brian
Re: cvs commit: httpd-2.0 CHANGES
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote:
> It's
> unreasonable to make the every admin responsible for hacking
> their start scripts to work around our broken product.
In what way is our product broken?
In order to use our product in certain ways your system may have
to be configured to allow our product to use more file descrioptors.
Now you have made it so that the apachectl script overrides my
environment limits, this is badness.
-aaron
Re: cvs commit: httpd-2.0 CHANGES
Posted by Brian Pane <br...@apache.org>.
Aaron Bannert wrote:
>I really don't like this. It adds unnecessary complexity to the configure
>script,
>
There's nothing unnecessary about it.
> misleads admins in to thinking that they have to rerun configure
>to set the file limit,
>
No, nowhwere do we say "you have to rerun configure to set
the file limit."
> and does something that should just be set by
>the admin themselves at starttime.
>
The need for a higher fd limit isn't due to any configuration
choice made by the admins, but rather due to a design decision
of the developers (using an architecture that requires hundreds
of descriptors per process, but not doing the setrlimit in the
process itself because it complicates the testing of the
out-of-descriptors error handling, as Jeff noted). It's
unreasonable to make the every admin responsible for hacking
their start scripts to work around our broken product.
--Brian