Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1 ID: 61873 User updated by:dcb at insomniacsoft dot com Reported by:dcb at insomniacsoft dot com Summary:proc_get_status always returns exitcode -1 Status: Open Type: Bug Package:Program Execution Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N New Comment: Ok, I think I've solved it. After some other tests I figured out it was a build config issue and in the end I narrowed it down to --enable-sigchild. I don't know why and without really understanding what it does I added that config option when I moved to php 5.4. It also breaks php 5.3. I've tested with php 5.3.6, 5.3.11 and 5.4.1 and after a clean build without --enable-sigchild proc_get_status will return the correct exitcode. I did a bit of research and found this article: https://blogs.oracle.com/opal/entry/php_oci8_signal_handling_and_e_1 Unfortunately I couldn't find the other bugs reporting this issue, but if they exist then this should be closed. Previous Comments: [2012-05-01 16:18:24] phpmpan at mpan dot pl 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);' 21 | grep '/tmp/te\|wait' -- [2012-05-01 01:12:19] dcb at insomniacsoft dot com Well, that is returning the proper exit code. It's strange that nobody else can reproduce this while I have it happening on 2 different Ubuntu machines. One is a 10.04 and the other one is 11.10. I was thinking that it might be something else, but keep in mind that on the same machine php 5.3 does work properly and returns the correct exit code in all the tests. [2012-05-01 00:28:56] phpmpan at mpan dot pl and you the code is executing it. In other should be: and the code is executing it. In the other Sorry [2012-05-01 00:27:25] phpmpan at mpan dot pl Since 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... [2012-04-30 23:24:42] dcb at insomniacsoft dot com 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) = 7 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=61873 -- Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
Bug #61873 [Fbk-Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1 ID: 61873 User updated by:dcb at insomniacsoft dot com Reported by:dcb at insomniacsoft dot com Summary:proc_get_status always returns exitcode -1 -Status: Feedback +Status: Open Type: Bug Package:Program Execution Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N New Comment: 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) = 7 Previous Comments: [2012-04-29 06:36:21] phpmpan at mpan dot pl 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);' 21 | grep '/tmp/te' [2012-04-29 03:51:46] larue...@php.net what about call /bin/ls instead of /tmp/te? [2012-04-29 00:18:47] dcb at insomniacsoft dot com I've checked that, the script executes fine and besides I actually discovered the issue while working with the symfony/Process classes. On php 5.3.6 all the tests pass, but on the same machine, with the same config (just different paths) all versions starting from 5.4.0 fail the symfony/Process unit tests related to the exit code. [2012-04-28 14:22:18] reeze dot xia at gmail dot com I can't reproduce it either. Any error log in /tmp/error-output.txt? maybe /tmp/te did't have execution permission? [2012-04-28 11:30:29] dcb at insomniacsoft dot com I forgot to mention that on the same machines php 5.3 gives the expected results. 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=61873 -- Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1 ID: 61873 User updated by:dcb at insomniacsoft dot com Reported by:dcb at insomniacsoft dot com Summary:proc_get_status always returns exitcode -1 Status: Open Type: Bug Package:Program Execution Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N New Comment: Well, that is returning the proper exit code. It's strange that nobody else can reproduce this while I have it happening on 2 different Ubuntu machines. One is a 10.04 and the other one is 11.10. I was thinking that it might be something else, but keep in mind that on the same machine php 5.3 does work properly and returns the correct exit code in all the tests. Previous Comments: [2012-05-01 00:28:56] phpmpan at mpan dot pl and you the code is executing it. In other should be: and the code is executing it. In the other Sorry [2012-05-01 00:27:25] phpmpan at mpan dot pl Since 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... [2012-04-30 23:24:42] dcb at insomniacsoft dot com 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) = 7 [2012-04-29 06:36:21] phpmpan at mpan dot pl 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);' 21 | grep '/tmp/te' [2012-04-29 03:51:46] larue...@php.net what about call /bin/ls instead of /tmp/te? 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=61873 -- Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
Bug #61873 [Fbk-Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1
ID: 61873
User updated by:dcb at insomniacsoft dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
-Status: Feedback
+Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
Previous Comments:
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] 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
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1
ID: 61873
User updated by:dcb at insomniacsoft dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I forgot to mention that on the same machines php 5.3 gives the expected
results.
Previous Comments:
[2012-04-28 11:25:59] dcb at insomniacsoft dot com
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] 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
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1
ID: 61873
User updated by:dcb at insomniacsoft dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I've checked that, the script executes fine and besides I actually discovered
the
issue while working with the symfony/Process classes. On php 5.3.6 all the
tests
pass, but on the same machine, with the same config (just different paths) all
versions starting from 5.4.0 fail the symfony/Process unit tests related to the
exit code.
Previous Comments:
[2012-04-28 14:22:18] reeze dot xia at gmail dot com
I can't reproduce it either. Any error log in /tmp/error-output.txt?
maybe /tmp/te did't have execution permission?
[2012-04-28 11:30:29] dcb at insomniacsoft dot com
I forgot to mention that on the same machines php 5.3 gives the expected
results.
[2012-04-28 11:25:59] dcb at insomniacsoft dot com
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] 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
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
[PHP-BUG] Bug #61873 [NEW]: proc_get_status always returns exitcode -1
From:
Operating system: Linux
PHP version: 5.4.1
Package: Program Execution
Bug Type: Bug
Bug description:proc_get_status always returns exitcode -1
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
)
--
Edit bug report at https://bugs.php.net/bug.php?id=61873edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61873r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61873r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61873r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61873r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61873r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61873r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61873r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61873r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61873r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61873r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61873r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61873r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61873r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61873r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61873r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61873r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61873r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61873r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61873r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61873r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61873r=mysqlcfg
