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

From: Date: Mon, 22 Feb 2010 19:16:37 +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-147962@lists.php.net to get a copy of this message 
 ID:               38915
 Comment by:       ionut dot dumitru at webland dot ro
 Reported By:      dimmoborgir at gmail dot com
 Status:           Analyzed
 Bug Type:         Feature/Change Request
 Operating System: UNIX
 PHP Version:      5.2.2, 4.4.7
 New Comment:

the problem is still there in 5.2 just with php not involving apache.
so i write a cli daemon A which uses a listener socket , at some point
it starts another daemon B with any of exec/system/popen etc. 'A' works
as a sort of supervisor for B so i can't shut it down. but at some point
i need to restart A, well I can't cause it won't bind to the same
listener address anymore because B is keeping the handles open. spent a
lot of time but i guess i have to go the file/cron way since php can't
clean itself.


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

[2009-12-23 18:45:09] devrim at kodingen dot com

Apparently Jeroen's closedexec.c code is not available from his
website,

here is my copy: http://pastie.org/754717

It is very useful to us, and that fix is still not there.

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

[2009-07-03 00:38:14] rasmus@php.net

This is finally fixed in Apache now.

https://issues.apache.org/bugzilla/show_bug.cgi?id=46425

It really is the responsibility of initiator of an fd to set the
O_CLOEXEC flag on it.  Going back and trying to do it after the fact is
really messy because we don't have direct access to these fds.  Since I
can't think of a portable way to get a list of all open fds, we would
have to pick some arbitrary number and loop through and set FD_CLOEXEC
on the first N fds.

Something like this:

Index: ext/standard/exec.c
===================================================================
RCS file: /repository/php-src/ext/standard/exec.c,v
retrieving revision 1.113.2.3.2.13
diff -u -r1.113.2.3.2.13 exec.c
--- ext/standard/exec.c	30 Apr 2009 15:25:05 -0000	1.113.2.3.2.13
+++ ext/standard/exec.c	3 Jul 2009 00:35:25 -0000
@@ -101,6 +101,17 @@
 	sig_handler = signal (SIGCHLD, SIG_DFL);
 #endif
 
+#if defined(F_SETFD) && defined(FD_CLOEXEC)
+	{
+		int i, oldflags;
+		for(i=0; i<10; i++) {
+			oldflags = fcntl(i, F_GETFD, 0);
+			oldflags |= FD_CLOEXEC;
+			fcntl(i, F_SETFD, oldflags);
+		}
+	}
+#endif
+
 #ifdef PHP_WIN32
 	fp = VCWD_POPEN(cmd_p, "rb");
 #else

and something similar would have to be done in the other places we
fork, like in mail().  This is extremely ugly, as far as I am concerned,
and likely doesn't catch everything anyway.

If someone sees a clean way of fixing this that I have missed, please
let us know.  Otherwise I would encourage you to upgrade your Apache or
lean on whatever web server you are using that is passing dirty fds to
us.


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

[2009-06-25 16:07:50] virus at tgu dot ru

OMG...
It's still didn't fixed... :(

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

[2008-08-26 13:08:53] anomie at users dot sf dot net

It seems that it could easily be fixed by having mod_php use the
Apache-provided functions which are intended to solve exactly this
problem, but the PHP developers seem to have decided to ignore this bug
instead.

Rather than a cron script, use a trampoline program like the one posted
by jeroen at unfix dot org; we have something similar here, although
ours doesn't impose an arbitrary run time limit.

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

[2008-08-20 13:28:45] peterspoon at abv dot bg

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

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

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 (#147962) next »