Passthru, Return Codes, Signals and Configuration PHP 5.3.3/Apache2/Centos5

broberts00

So I have a problem where passthru doesn't seem to be handling the ulimit as expected on Centos.

My php is simply:

<?php 
echo "<pre>";
passthru('/bin/myscript.sh',$return_code);
echo "<br>";
echo "Got $return_code as always";
echo "</pre>";
?>

The bash is simply:

#!/bin/bash
bail()
{
echo "File too large detected via signal."
exit 12
}

trap bail SIGXFSZ

# set max wirte size to 2.1 MB
ulimit -f 2100  

# check that it's set
ulimit -a
# see we're ok
# file size               (blocks, -f) 2100

cp /path/5mb_file /path/5mb_file.cp
LOCALRET=$?

# return code = 128+SIGXFSZ = 153 (on my Centos anyway)
if [[ ${LOCALRET} -eq 153 ]]; then
 echo "File too large detected via return code"
else
 echo "Got ${LOCALRET}"
fi

exit 0

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 I assume the cp child process caught and handled the SIGXFSZ signal and there is nothing for the parent myscript.sh to catch.

But when I run the PHP script while the o/s stops the cp at 2.1 MB, ${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).

Interesting side note here that is probably related is the if 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 compile setting in PHP to make the Centos behave like the MacOS for signals (like --enable-sysvmsg or such)?? Right now it's just:

./configure --with-mysqli --with-zlib --with-xml --with-mysql --with-openssl --enable-sockets --enable-calendar --with-curl --with-apxs2

Thanks in advance!!

sneakyimp

I'm not entirely sure what you're saying here, but the script is going to echo something -- either "file too large detected..." or "got ${LOCALRET}". This output is going to be returned to PHP which will output it. This is what [man]passthru[/man] does.

I suspect I'm missing something in what you are describing. Not sure what you mean by "the child of myscript.sh isn't getting the signal properly". My guess is that you should have myscript.sh echo whatever LOCALRET it is getting and start there. This value may differ between Mac and Centos.

broberts00

I'm not entirely sure what you're saying here, but the script is going to echo something -- either "file too large detected..." or "got ${LOCALRET}". This output is going to be returned to PHP which will output it. This is what passthru does.

Right, that's what the script does -- the output is there. :-) This issue is that the LOCALRET value when running via PHP on Centos5 is different (and incorrect from my view of things) than via the command line (and PHP on Mac OS).

cp is the child process of myscript.sh. cp writes filesize beyond 2.1 MB, so it would be sent the SIGXFSZ signal, right? The process should terminate when the SIGXFSZ signal is handled and return 128+SIGXFSZ = 153 (for both Centos5 and Mac OS). Running myscript.sh at the bash shell on both Centos and Mac OS returns the same output:
File too large detected via return code

That's also what I see on PHP 5.3.3/Apache2 on Mac OS. On PHP 5.3.3/Apache2 on Centos5 however I see:
Got 1

sneakyimp

I wonder if perhaps PHP on CentOS that PHP uses a different shell environment besides bash when running commmand line scripts? This could either account for the value that's not 153 -- or perhaps ulimit is not meaningful in some other shell. You might want to put a shebang in your shell script.

Also, isn't zero the only result that means success from a script? Do you really want to check for anything more specific than zero or something else? Forgive me as my knowledge here is fairly thin.

Also, am I right in understanding that your cp command under PHP/CentOS is exceeding the ulimit you try to set in your script? If so, perhaps ulimit is not a meaningful command in this other shell environment?

Sorry I can't be of more help here.

broberts00

sneakyimp;10969850 wrote:
I wonder if perhaps PHP on CentOS that PHP uses a different shell environment besides bash when running commmand line scripts? This could either account for the value that's not 153 -- or perhaps ulimit is not meaningful in some other shell. You might want to put a shebang in your shell script.

That's interesting idea, though I already have the shebang in my script.

Also, isn't zero the only result that means success from a script? Do you really want to check for anything more specific than zero or something else? Forgive me as my knowledge here is fairly thin.

You're correct that 0 == success. 1 is rather broad failure message. If the process is killed by a signal it should return 128 + signal value (see kill -l for the values on your o/s).

What I'm hoping to do is give a better error message to the end user that we were unable to complete the request due to file getting too big (we are BTW in the real world doing a lot more than a simple cp).

Also, am I right in understanding that your cp command under PHP/CentOS is exceeding the ulimit you try to set in your script? If so, perhaps ulimit is not a meaningful command in this other shell environment?

The cp is exceeding the ulimit and it seems to behave as expected on both CentOS and Mac OS -- i.e the resultant file never exceeds 2.1 MB. The MacOS seems to get the return code right (and properly terminate the process) though...

Sorry I can't be of more help here.

Hey thanks for the effort! I'm thinking that this might be configuration issue. The build parameters for the Mac OS build are different than the CentOS ones and I suspect one of those flags impacts signaling for PHP.

sneakyimp

I hope you can figure it out to your liking. I've contributed as much as I can I think.

broberts00

Hmm -- this may be related right here: http://bugs.php.net/bug.php?id=52992

Thanks!