|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2012-04-28 03:13 UTC] dcb at insomniacsoft dot com
Description:
------------
Since PHP 5.4.0 the proc_get_status and proc_close functions always return -1 as
exitcode.
Test script:
---------------
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$p = proc_open('/tmp/te', $descriptorspec, $pipes, '/tmp');
sleep(1);
fclose($pipes[0]);fclose($pipes[1]);
$s = proc_get_status($p);
print_r($s);
/tmp/te is simply:
#!/bin/bash
exit 0
Expected result:
----------------
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => 0
[termsig] => 0
[stopsig] => 0
)
Actual result:
--------------
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => -1
[termsig] => 0
[stopsig] => 0
)
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 22:00:01 2025 UTC |
Maybe strace shows something interesting? strace -f php -r '$descriptorspec = array( 0 => array("pipe", "r"), 1 => array("pipe", "w"), 2 => array("file", "/tmp/error-output.txt", "a") ); $p = proc_open("/tmp/te", $descriptorspec, $pipes, "/tmp"); sleep(1); fclose($pipes[0]);fclose($pipes[1]); $s = proc_get_status($p); print_r($s);' 2>&1 | grep '/tmp/te'Still getting -1 for /bin/ls as well I did the strace, here is output, unfortunately I have no idea how to interpret it: [pid 26199] execve("/bin/sh", ["sh", "-c", "/tmp/te"], [/* 19 vars */] <unfinished ...> [pid 26200] execve("/tmp/te", ["/tmp/te"], [/* 19 vars */]) = 0 [pid 26200] open("/tmp/te", O_RDONLY) = 3 write(1, "/tmp/te", 7/tmp/te) = 7Since no one was able to reproduce this to this point, all that can be done is debugging it somehow on your side and eliminate possible reasons. What strace output tells us here is that "/tmp/te" actually exists and you the code is executing it. In other case the second call to `execve` would not return 0. If it is returning 0, it means that the interpretation of "/tmp/te" has actually started. He's my output for comparison (snaps for 5.4 and trunk): ------------------------------- [pid 7359] execve("/bin/sh", ["sh", "-c", "/tmp/te"], [/* 47 vars */] <unfinished ...> [pid 7359] execve("/tmp/te", ["/tmp/te"], [/* 46 vars */]) = 0 [pid 7359] open("/tmp/te", O_RDONLY) = 3 write(1, "/tmp/te", 7/tmp/te) = 7 ------------------------------- What is puzzling me is why your `sh` (pid:26199) is not replacing itself with the script. As we can see, another process (pid:26200) is spawned and it is the one that executes your script. My blind guess is that PHP receives status code from 26199, which - for some reason - is not waiting for 26200 or not passing the status code from it properly. Can you check what is this producing? ------------------------------- sh -c /tmp/te echo $? ------------------------------- Maybe the bug is not in PHP...Have you tried testing this on non-Ubuntu box? Maybe it's something that depends on Ubuntu configuration? I still don't like the fact that a second process is spawned after the one PHP is starting. The following code should also show calls to `wait` and values that are returned from processes. ------------------------------------------ strace -f php -r '$descriptorspec = array( 0 => array("pipe", "r"), 1 => array("pipe", "w"), 2 => array("file", "/tmp/error-output.txt", "a") ); $p = proc_open("/tmp/te", $descriptorspec, $pipes, "/tmp"); sleep(1); fclose($pipes[0]);fclose($pipes[1]); $s = proc_get_status($p); print_r($s);' 2>&1 | grep '/tmp/te\|wait' ------------------------------------------