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

 ID:               38915
 Comment by:       peterspoon at abv dot bg
 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:

SO, can this problem be fixed within PHP/Apache or it cannot?
Do you think using funny scripts started by cron is a solution?


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

[2008-05-27 15:12:09] jeroen at unfix dot org

My solution to this very annoying issue (especially when Apache is
reloaded and the from PHP spawned app is still running and your
webserver thus simply dies off as the apache processes are gone, but the
spawned app keeps port 80 etc open for you, thus making Apache never
start again...

http://unfix.org/~jeroen/archive/closedexec.c

Compile: cc -o /usr/bin/closedexec closedexec.c

Just call it like: system("/usr/bin/closedexec /path/to/exe arg arg
arg") or whatever call you where using in PHP.

It first closes all sockets !1|!2 (stdout/stderr), setsid()'s, forks,
and then execv's the args given, doing a waitpid() in the other thread
and killing the process when it runs longer than 5 minutes.

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

[2008-04-30 00:06:18] support at ppnhosting dot com

5.2.3
also experiencing this 'bug' to the point of having to manually kill
Exim to just Apache restarted.. the mail() function is suffering from
the same problem. It is very annoying to see Apache failing to 
restart, because the MTA (exim via sendmail in our case) is already 
listening on port *:80

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

[2008-03-07 10:45:53] martin at activevb dot de

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?

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

[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)

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

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