ID: 38915 Comment by: anomie at users dot sf dot net Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment:
On 29 Jan 6:20pm UTC, adrian dot rollett at unt dot edu wrote: > > For those of you that found this page while looking for info on why > exim is blocking port 80 after inheriting apache's file descriptors, > I believe I found the reason for this. It seems that exim will only > work with a maximum of 1000 file descriptors, (or 256 on older > systems) after which point it will hang, consuming all available cpu > cycles, and preventing apache from restarting. You should submit more detailed information on this to Exim's bug tracking system so it has a chance of being fixed. As far as this ridiculous bug, I've been working around it by using a small program that closes all FDs above 2 (either via the F_CLOSEM fcntl, reading /proc/self/fd, or just blindly calling close for every possible fd) and then execs the real program. Previous Comments: ------------------------------------------------------------------------ [2008-01-29 18:20:39] adrian dot rollett at unt dot edu For those of you that found this page while looking for info on why exim is blocking port 80 after inheriting apache's file descriptors, I believe I found the reason for this. It seems that exim will only work with a maximum of 1000 file descriptors, (or 256 on older systems) after which point it will hang, consuming all available cpu cycles, and preventing apache from restarting. The only possible solutions I have found: 1. modify the source, and re-compile exim with a higher file descriptor limit. 2. run a cron job at regular intervals to search for hung exim processes and kill them. 3. switch MUAs. (postfix may fail more gracefully, but I haven't tried this yet) ------------------------------------------------------------------------ [2007-12-06 21:41:36] jameskyle at ucla dot edu Whether the blame lie with Apache or PHP is irrelevant. It directly impacts the security of PHP. Thus, the PHP team should work on a fix or apply substantial and vocal pressure on the Apache team. This would at least open discourse and allow the two teams to work toward a solution and determine the quickest path. The fact that this has remained a bug for an entire year is unacceptable. As is the relative silence on the topic from both of the primary development teams. ------------------------------------------------------------------------ [2007-12-06 20:56:01] gabe-php at mudbugmedia dot com I'm also running into a problem where, because my Apache is hosting 500+ vhosts, gobbling up 1000+ descriptors for logs. All this gets passed to any program it executes, causing problems with processes with a 1024 limit compiled in. Apache might be able to deal with having that many descriptors open, but we shouldn't assume anything PHP execs should. ------------------------------------------------------------------------ [2007-12-04 19:14:45] [EMAIL PROTECTED] I think that's exactly what FD_CLOEXEC does. ------------------------------------------------------------------------ [2007-12-04 18:43:04] crescentfreshpot at yahoo dot com Just to add to the dialog, Apache 1.x seems to have tried to address the issue of leaked FDs itself. http://www.apache.org/dist/httpd/CHANGES_1.3 says: Changes with Apache 1.3.28 *) Certain 3rd party modules would bypass the Apache API and not invoke ap_cleanup_for_exec() before creating sub-processes. To such a child process, Apache's file descriptors (lock fd's, log files, sockets) were accessible, allowing them direct access to Apache log file etc. Where the OS allows, we now add proactive close functions to prevent these file descriptors from leaking to the child processes. As far as I understand the above, apache thinks it can know when [mod_]php does a system-level popen() and cleanup the parent FDs before exec(). Is that actually possible? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38915 -- Edit this bug report at http://bugs.php.net/?id=38915&edit=1
