Edit report at https://bugs.php.net/bug.php?id=38915&edit=1
ID: 38915
Comment by: oliver at realtsp dot com
Reported by: dimmoborgir at gmail dot com
Summary: Apache: system() (and similar) don't cleanup opened
handles of Apache
Status: Analyzed
Type: Feature/Change Request
Package: Program Execution
Operating System: UNIX
PHP Version: 5.2.2, 4.4.7
Block user comment: N
Private report: N
New Comment:
we solved by passing the forked/exec'd process through a bash shell and closing
all te file
descriptors: eg: (note this is for FreeBSD using daemon, but "nohup" should
work
on linux)
daemon /usr/bin/env bash -c 'exec 0<&-; exec 1> /path/to/error/log; exec 2>
/path/to/stdout/log;
eval exec {3..255}\>\&-; /usr/bin/env php /path/to/script args...'
Note we find it crucial to redirect and NOT CLOSE STDOUT and STDERR because
otherwise you will
never find out if sth is wrong with forked process. You should ensure that they
exist and are
writable before forking.
The trick with eval exec {3..255}\>\&-; is from here:
http://blog.n01se.net/blog-n01se-net-p-145.html
This works for us in a php-fastcgi situation. the fastcgi-socket and the mysql
socket are both
closed successfully. the new process opens its own mysql socket just fine...
I suspect this is similar to what Jeroen's closedexec.c does, but no need for a
c program.
Everyone should have bash.
If you redirect the stdout of above fork command to a file and check the
contents of that daemon
gives you nice messages, just append
2> /path/to/temp/stderr/file/for/daemon/messages
to the above command.
We have the construction of the fork command wrapped in a simple function, like
so:
$exec_cmd = ((php_uname('s') == 'FreeBSD') ? 'daemon' : 'nohup') .
// try to
be OS agnostic, daemon = fork, setguid etc, but don't close stderr with -f
' /usr/bin/env bash -c ' .
// wrap
actual call to new php process in a shell (use env!), so
// must escape here in case the already escaped args contain
// specials chars like single quotes (which the will!)
escapeshellarg(
'exec 0<&-; ' .
// close
STDIN
'exec 1> ' . escapeshellarg($app_log) . '; ' .
// STDOUT
> app_log
>
'exec 2> ' . escapeshellarg($error_log) . '; ' .
// STDOUT
> error_log
>
'eval exec {3..255}\>\&-; ' .
// we can
close all other fds (fastcgi, mysql, etc)..eval trick!
'/usr/bin/env php ' . BASE . $cmd . ' ' .
// call
php (with env!) don't rely on shebang or exec perms
join(' ',
// add
args separated by spaces
array_map(function ($arg) { return escapeshellarg($arg); },
$args))
// after
escaping them
);
Sorry about the formatting...
Previous Comments:
------------------------------------------------------------------------
[2010-04-16 01:31:48] crrodriguez at opensuse dot org
In linux, this should fix the issue for mail()
diff --git a/ext/standard/mail.c b/ext/standard/mail.c
index ab65f16..a8b3bf5 100644
--- a/ext/standard/mail.c
+++ b/ext/standard/mail.c
@@ -288,8 +288,12 @@ PHPAPI int php_mail(char *to, char *subject, char
*message,
char *headers, char
* (e.g. the shell can't be executed) we explicitely set it to 0 to be
* sure we don't catch any older errno value. */
errno = 0;
+#if defined(__linux__) && defined(__GLIBC__) && __GLIBC_PREREQ(2, 9)
+ sendmail = popen(sendmail_cmd, "we");
+#else
sendmail = popen(sendmail_cmd, "w");
#endif
+#endif
if (extra_cmd != NULL) {
efree (sendmail_cmd);
}
Note that you need glibc 2.9 though.
------------------------------------------------------------------------
[2010-02-22 19:16:37] ionut dot dumitru at webland dot ro
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.
------------------------------------------------------------------------
[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] [email protected]
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... :(
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=38915
--
Edit this bug report at https://bugs.php.net/bug.php?id=38915&edit=1
