Bug #53489 [Opn->Fbk]: Passthru and Signals Appear Not Handled
| From: | cmb@php.net | Date: | Tue, 13 Apr 2021 12:00:59 +0000 |
| Subject: | Bug #53489 [Opn->Fbk]: Passthru and Signals Appear Not Handled | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-233388@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=53489&edit=1
ID: 53489
Updated by: cmb@php.net
Reported by: broberts at ieee dot org
Summary: Passthru and Signals Appear Not Handled
-Status: Open
+Status: Feedback
Type: Bug
Package: Unknown/Other Function
Operating System: Centos5
PHP Version: 5.3.3
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> are you using a 100 year old version of PHP? 5.3.3?
Well, that tickets has been filed more than ten years ago.
Anyhow, is this still an issue with any of the actively supported
PHP versions[1]?
[1] <https://www.php.net/supported-versions.php>
Previous Comments:
------------------------------------------------------------------------
[2020-10-11 13:09:05] divinity76 at gmail dot com
are you using a 100 year old version of PHP? 5.3.3? that one is no longer supported (maybe Red Hat
still support 5.3.3, in which case go complain to Red Hat's bugtracker, not PHP's
bugtracker)
see if the problem reproduce itself in a supported version of PHP, 7.2 or 7.3 or 7.4
for what it's worth, here's what i get:
hans@xDevAd:~$ cat foo.php
<?php
$filepath="/tmp/test_script_file.sh";
$fileh=fopen($filepath,"wb");
$code='
#!/bin/sh
cd /tmp
ulimit -f 2100
dd if=/dev/zero of=5mb_test_file.bin bs=5M count=1
';
fwrite($fileh,$code);
chmod($filepath,0555);
fclose($fileh);
passthru($filepath,$ret);
var_dump($ret,filesize("/tmp/5mb_test_file.bin"));
unlink("/tmp/5mb_test_file.bin");
unlink("/tmp/test_script_file.sh");
hans@xDevAd:~$ php foo.php
File size limit exceeded (core dumped)
int(153)
int(1075200)
- as expected.
------------------------------------------------------------------------
[2010-12-06 23:08:23] broberts at ieee dot org
Description:
------------
So I'm not really sure if this is a configuration issue or a bug, but passthru doesn't
seem to be handling the signal due to ulimit as expected on Centos5.
If I run myscript.sh at the bash command line, I get a nice "File too large detected via return
code" show up and 2.1 MB of the 5 MB file copied. So it appears cp child process caught and
handled the SIGXFSZ signal.
But when I run the PHP script, while the o/s stops cp at 2.1 MB, but ${LOCALRET} is 1 (of course I
also see the "Got 0 as always" message as myscript.sh always returns 0). Somehow the child
of myscript.sh isn't getting the signal properly it seems. In fact if it's a more
elaborate process than a cp, it will not stop the process -- The process appears not to have gotten
the signal (of course the o/s won't let it write more than 2.1 MB but it seems to be obvious to
the signal).
When I'm on MacOS (running same PHP 5.3.3 with Apache 2) the signals seem to work correctly. So
am I misunderstanding something here? Is there a configuration setting in PHP to make the Centos
behave like the MacOS? Or is this a Centos PHP bug?
BTW the Centos configure options are:
./configure --with-mysqli --with-zlib --with-xml --with-mysql --with-openssl --enable-sockets
--enable-calendar --with-curl --with-apxs2
Test script:
---------------
<?php
echo "<pre>";
passthru('/bin/myscript.sh',$return_code);
echo "<br>";
echo "Got $return_code as always";
echo "</pre>";
?>
#!/bin/bash
# set max write size to 2.1 MB and trigger SIGXFSZ
ulimit -f 2100
cp /path/5mb_file /path/5mb_file.cp
LOCALRET=$?
# return code = 128+SIGXFSZ = 153 (on Centos and MacOS anyway)
if [[ ${LOCALRET} -eq 153 ]]; then
echo "File too large detected via return code"
else
echo "Got ${LOCALRET}"
fi
exit 0
Expected result:
----------------
File too large detected via return code
Got 0 as always
Actual result:
--------------
Got 1
Got 0 as always
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=53489&edit=1