#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache

From: Date: Tue, 29 Jan 2008 18:20:40 +0000
Subject: #38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-121751@lists.php.net to get a copy of this message 
 ID:               38915
 Comment by:       adrian dot rollett at unt dot edu
 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:

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)


Previous Comments:
------------------------------------------------------------------------

[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] stas@php.net

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?

------------------------------------------------------------------------

[2007-11-29 20:33:42] odeta at hard dot lt

Any news? mail() function is suffering from the 
same problem, and exim is using Apache port then..

------------------------------------------------------------------------

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

Thread (50 messages)

« previous php.bugs (#121751) next »