ID: 38915 Comment by: Cruz at guerillamail dot com 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:
Ran into the same problem. I'm appalled that a bug this big isn't fixed more than a year after it was reported. Previous Comments: ------------------------------------------------------------------------ [2007-07-29 10:48:18] antoine dot bajolet at tdf dot fr Hello, I agree with all contributors : It's a bunch of pain we can't launch a clean process from a PHP web interface. Without any technical consideration, functionally it's a real need to numerous PHP users, and for a long time seeing those bug reports : http://bugs.php.net/bug.php?id=15529 http://bugs.php.net/bug.php?id=15642 http://bugs.php.net/bug.php?id=16548 The only workaround whe found to obtain the result is : - Writing something to a file to tell "hey, there is a process to launch or stop" - Using a cron'ed script to read the file and launch/stop the process if it tells it. And this poor tip is far far from satisfying us. The last response given in 2003 was "Given the nature of PHP's execution architecture this is not possible/practical to implement." But if the Apache API offers a "apr_proc_create()" function, why not using it in mod_php ? There are some other differences between mod_php and php-cli. Regards, Antoine ------------------------------------------------------------------------ [2007-03-05 21:11:51] oliver at realtsp dot com apart from the security considerations mentioned above the fact that mod_php doesn't free the FDs when forking prevents us from forking cleanly. ie we cannot from a web request to mod_php fork a cli process cleanly because it will inherit all the open FDs (ie typically port 80 & 443) even if you use setsid() (or daemon on FreeBSD) etc.. you can see this when you... fork stop apache netstat -an | grep LISTEN your cli process will be LISTENING to port 80 & 443. this is not only a security risk, but it will prevent apache for restarting: (48)Address already in use: make_sock: could not bind to address [::]:443 no listening sockets available, shutting down I have not found any way to close these sockets as they should be because the resource handles are not available in php. If you could at least make these available then we could at least ensure we close them manually. Regards Oliver ------------------------------------------------------------------------ [2007-01-04 19:25:26] anomie at users dot sf dot net On 20 Oct 2006 9:48am UTC, [EMAIL PROTECTED] wrote: > The opened file descriptors are opened by Apache. > It is the job of Apache to protect them, not something that > should be reinvented in all apache modules. If that's your position, then as far as I can tell mod_php should be calling apr_proc_create() instead of system()/popen()/etc and apr_pool_cleanup_for_exec() before exec(). Apache adds (or should be adding) all the FDs that should be closed on exec to a list that those functions make use of. If you don't like that, then either explain (in as much detail as is required) why that isn't Apache's method of protecting the FDs, find a non-bogus reason for claiming this issue is not a mod_php bug, or just fix the bug already. "Apache should just use FD_CLOEXEC" isn't a non-bogus reason, BTW, although convincing Apache to do so and making sure FD_CLOEXEC is supported on all platforms mod_php can possibly be used on might be an acceptable bugfix. I've also seen the "MTA ends up listening on port 80" issue after using the php mail functions. ------------------------------------------------------------------------ [2006-11-23 15:36:55] php at vanviegen dot net It seems that the mail() function is suffering from the same problem. It is rather scary to see Apache failing to restart, because the MTA (exim in our case) is already listening on port *:80 ! More details: http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20030407/msg00049.html ------------------------------------------------------------------------ [2006-10-30 16:55:36] jlawson-php at bovine dot net It should be PHP's responsibility to close all open file handles (after forking but before the exec). Keep in mind that PHP is running as a module within the same process space as Apache, and those private FDs are required for it to operate. Apache cannot reasonably close and re-open all of those whenever it is invoking a module's handlers, nor can it reasonably run modules in a separate process. Modules are intended to be trusted code and so Apache does not attempt to protect itself from misdesigned modules. (In the case where PHP is installed as a CGI and not a module, then Apache does indeed close the private FDs prior to running PHP.) For example, when a CGI process via Apache's "mod_cgi", that module is responsible for ensuring that it explicitly closes all open files prior to the exec(). PHP is in a similar situation and should also do the same when executing sub-processes. Passing blame to Apache by saying that they should use "close on fork" fcntl is not reasonable. Its current expectation is that modules which need to fork will explicitly close files (as demonstrated by mod_cgi's own implementation). ------------------------------------------------------------------------ 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
