ID: 44994
Comment by: jkflash at gmail dot com
Reported By: dbarrett at vistaprint dot com
Status: Assigned
Bug Type: Program Execution
Operating System: Windows 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
PS: shell_exec() DOES seem to work without hanging on my setup, but
none of the others.
Previous Comments:
------------------------------------------------------------------------
[2008-08-12 23:50:58] jkflash at gmail dot com
I am experiencing this same problem with PHP 5.2.1 running on IIS as an
ISAPI module on Windows Server 2003 R2 SP2. Intermitently (a handful of
times in a hundred) a process started with exec() will appear to
complete ok but remain running in a zombie state. The IIS worker process
that created the process will not respond to any further requests. I
need to either open a new client browser or kill the worker process.
I get the same result with system, passthru, p_open and proc_open.
------------------------------------------------------------------------
[2008-07-29 15:03:40] nobody at dontsendmespam dot com
i can reproduce this problem on a debian server with apache2 and
php5.2.6 running as fcgi
------------------------------------------------------------------------
[2008-07-23 02:02:29] efesar at gmail dot com
I just upgraded from PHP 5.1.2 to 5.2.6, and this exact problem happens
to me. The exec and shell_exec used to work, and now they don't. They
hang the php process, and every subsequent call to exec produces a lost
cmd.exe ...
Incidentally passthru() causes the same behavior.
Maybe it has something to do with the rotatelogs.exe ... somebody
earlier mentioned that it was waiting on c:\Apache2\logs\error.log ...
So, basically, we can't run any system calls whatsoever via PHP. I
don't want to use a COM object, because I like portable code ... but
that might be the best step until this bug is fixed.
------------------------------------------------------------------------
[2008-07-07 18:57:12] stephen dot cuppett at sas dot com
I am also experiencing this problem. I have been able to recreate it
with system() as well as proc_open(). With proc_open() it doesn't seem
to matter if I set bypass_shell or not, just determines whether I have a
dangling cmd.exe process or not...
cmd.exe seems to stop at Wait:UserReq, but that probably doesn't mean
much.
I am able to reproduce it with XAMPP 1.6.6a (PHP 5.2.5) on Windows XP
or Windows Server 2003 (32-bit).
I don't have much to add in terms of documentation as I don't get
anything in the httpd logs, but using the following code snippet:
protected function runSAS($filename) {
$this->log("Requested to run SAS file:
" . $filename, LOG_DEBUG);
$toRun = "\"" . SAS . "\"";
$toRun .= " -sysin '" . $filename .
"'";
$toRun .= " -CONFIG '" . SASV9CFG .
"'";
$toRun .= " -PRINT '" . TEMP_DIR . "/"
. basename($filename) . ".lst'";
$toRun .= " -LOG '" . TEMP_DIR . "/" .
basename($filename) . ".log'";
$toRun .= " -NOSPLASH";
$this->log("SAS command to run: " .
$toRun, LOG_DEBUG);
$descriptorspec = array(
0 => array("pipe",
"r"), // stdin is a pipe that the child will read from
1 => array("pipe",
"w"), // stdout is a pipe that the child will write to
2 => array("pipe", "w")
// stderr is a file to write to
);
$res = proc_open($toRun,
$descriptorspec, $pipes, null, null, array(/*"bypass_shell" =>
true*/));
if (is_resource($res)) {
//fwrite($pipes[0],
"exit\n");
//fflush($pipes[0]);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
$return_value =
proc_close($res);
$this->log("Return
value from SAS: " . $return_value, LOG_DEBUG);
}
}
When it does seem to complete, I'll get this in my log:
2008-06-26 20:23:55 Debug: Return value from SAS: 1
Nothing should come out on the pipes at all and when I set it up to
read those and it completes, there is no data read. However, in a hang
case, PHP blocks reading STDOUT instead of on proc_close never getting
any data... even if I set the stream to be non-blocking on the pipe
explicitely after proc_open.
------------------------------------------------------------------------
[2008-05-29 13:21:51] dbarrett at vistaprint dot com
I replaced all occurrences of exec() and shell_exec() in MediaWiki with
calls to a custom COM object that invokes programs. The problem went
away. This strongly suggests that PHP's implementation of exec(0 and
shell_exec() is the culprit. I suspect a race condition.
------------------------------------------------------------------------
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/44994
--
Edit this bug report at http://bugs.php.net/?id=44994&edit=1
