ID: 38915
Comment by: martin at activevb dot de
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:
Will this ever be fixed... or shall we better rewrite our 30000 lines
of PHP code in Perl? :-|
Is it possible to use apr_proc_create() and apr_pool_cleanup_for_exec()
directly from PHP source code without patching PHP?
Previous Comments:
------------------------------------------------------------------------
[2008-02-19 03:59:36] anomie at users dot sf dot net
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
