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
Product: Red Hat Linux
Classification: Retired
Component: httpd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Depends On:
  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:
Last Closed: 2004-04-30 03:15:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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):


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.

brk(0)                                  = 0x94c5000
brk(0x94c7000)                          = 0x94c7000
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/", O_RDONLY) =
(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


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 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.

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 :(.

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

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.

Comment 9 Joe Orton 2004-02-25 15:28:24 EST
Actually, I've just built binaries here:
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?

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.

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