This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 116576 - Apache2 fails to start with more than 1024 FDs
Apache2 fails to start with more than 1024 FDs
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: httpd (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-23 08:24 EST by Stuart Low
Modified: 2007-04-18 13:03 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-30 03:15:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stuart Low 2004-02-23 08:24:56 EST
Description of problem:

Apache2 doesn't allow any more than 1024 File descriptor handles to be
opened. This is AFTER a manual recompilation following the
modification of typesizes.h (/usr/include/bits), posix_types.h
(/usr/include/linux) and the httpd init script (adding a ulimit -n
32768 to the start() function).

Version-Release number of selected component (if applicable):

httpd-2.0.40-21.9


How reproducible:

Steps to Reproduce:
1. Create enough Vhosts to push the FDs over 1024
2. Restart Apache (it'll Die).
  
Actual results:

Apache promptly dies when it hits FD number 1024.


Expected results:

Apache should start.


Additional info:

Have modified the referenced .h files Apache uses (I think).
Personally, I think this problem is VERY short sighted by the Apache
dev team (reading the values from some obscure header files).
Comment 1 Stuart Low 2004-02-23 08:26:42 EST
Snippet from an strace:

Full strace available, drop me an email.

open("/home/httpd/vhosts/davesanimalfarm.com/statistics/logs/access_log",
O_WRONLY|O_APPEND|O_CREAT, 0666) = 1021
open("/home/httpd/vhosts/davesanimalfarm.com/statistics/logs/access_ssl_log",
O_WRONLY|O_APPEND|O_CREAT, 0666) = 1022
open("/home/httpd/vhosts/kbws.net/statistics/logs/access_log",
O_WRONLY|O_APPEND|O_CREAT, 0666) = 1023
brk(0)                                  = 0x94c5000
brk(0x94c7000)                          = 0x94c7000
open("/home/httpd/vhosts/kbws.net/statistics/logs/access_ssl_log",
O_WRONLY|O_APPEND|O_CREAT, 0666) = -1 EMFILE (Too many open files)
gettimeofday({1077113225, 632806}, NULL) = 0
open("/etc/localtime", O_RDONLY)        = -1 EMFILE (Too many open files)
open("/usr/share/locale/locale.alias", O_RDONLY) = -1 EMFILE (Too many
open files)
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) =
-1 EMFILE
(Too many open files)
Comment 2 Stuart Low 2004-02-23 08:27:34 EST
In all the .h files mentioned above I've specified __FD_SETSIZE to be
32768 (from the default 1024). No avail. :( Help..
Comment 3 Stuart Low 2004-02-23 08:29:22 EST
Sorry about all these additional comments.

Just for reclarification "manual recompilation" means:

rpm --rebuild httpd-....src.rpm

Etc.

Stuart
Comment 4 Joe Orton 2004-02-23 08:37:34 EST
Apache has an unnecessary check for FD_SETSIZE in os/unix/unixd.c
which you can simply remove rather than modifying the __FD_SETSIZE
define!  The FD_SETSIZE limit has no practical affect since httpd uses
poll() rather than select(), I believe.

I believe EMFILE does mean you're just hitting the rlimit rather than
any other system limit, are you sure the ulimit -n took effect?

BTW, "GinGin64" was a technology preview; did you mean to file the bug
against that product?

Comment 5 Stuart Low 2004-02-23 19:43:09 EST
Hey Joe,

The unixd.c check dies with an error. Apache seems to simply fault
without a single error (to error_log or otherwise). The only way to
get info is strace.

I'm sure the ulimit -n takes affect. Demo URL at
http://bondi.aussiehosts.com/cgi-bin/ulimit.pl. That's a script
running ulimit -a on the box and build in question.

Finally, no, I'm sure I selected 9 when I submitted the bug. Have
changed it now anyways.

Stuart
Comment 6 Stuart Low 2004-02-25 11:44:45 EST
Heya Joe,

No chance of a solution? I'd imagine this bug would be occuring in all
Apache2 RPMs so I wouldn't mind figuring out how to fix it :(.

Stuart
Comment 7 Joe Orton 2004-02-25 11:51:51 EST
As far as I can work out, EMFILE is only given when the rlimit is
reached, so I'm confused.  Checked that /proc/sys/fs/file-max is set
appropriately?

But: how do you get to trigger the unixd.c check? That implies that
you *have* managed to get past the default 1024 rlimit.  We can supply
a test SRPM which has a patch to remove the unixd.c check.
Comment 8 Stuart Low 2004-02-25 13:11:32 EST
Hey Joe,

Could you supply the test SRPM? I'll have a shot at using that.

Stuart
Comment 9 Joe Orton 2004-02-25 15:28:24 EST
Actually, I've just built binaries here:

http://people.redhat.com/jorton/Shrike-httpd/
Comment 10 Joe Orton 2004-03-08 05:14:23 EST
Did you have any luck with these Stuart?
Comment 11 Stuart Low 2004-03-09 04:58:33 EST
Hi Joe,

Yeah I replied to this but anyways, it seems to have disappeared. Yes
the Shrike-httpd/ RPMS worked. Could you supply the SRPM though?

Stuart
Comment 12 Joe Orton 2004-03-09 05:02:40 EST
Great, thanks for testing.  The SRPM will be uploaded later today.
Comment 13 Mark J. Cox (Product Security) 2004-04-30 03:15:38 EDT
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2004-182.html

Note You need to log in before you can comment on or make changes to this bug.