php5 cli one instance/process limit

[KnightMB]

# lsb_release -rd
Description: Ubuntu 13.10
Release: 13.10

php5-cli 5.5.3+dfsg-1ubuntu2.1

Ubuntu 13.10 32 bit

PHP5-cli limits the user to one instance at a time. If another php5-cli script is started, it takes priority over the previous running script causing the previous to "freeze" until the new running script finishes or exits. This isn't the normal behavior of the php5-cli as it should not care how many scripts you are running at once. I've never seen this behavior before, seems to be unique to only the Ubuntu distro family.

How to duplicate.
Create a script that loops a lot or does a lot of complex math to cause a good few seconds delay while it processes. Create another script (or copy/paste the first one) by a different file name. Try to run both scripts at the same time (you'll need two console sessions to do it) and the last executed script will freeze the first script until it finishes, then the first script will be allowed to process and finish.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I was unable to reproduce the problem. I ran two scripts with sleep statements, and one process does not appear to block the other.

I also tried a long for loop in case it helped to reproduce by keeping the CPU spinning, and I also could not get one process to block the other.

Finally, I tried three processes, since I was running the tests on a 2-CPU VM and wanted to make sure I tried the case where the number of processes exceeds the number of available CPUs.

None of these test cases were able to reproduce your problem. All processes ran in the time expected.

I appreciate your attempt to provide instructions to reproduce the problem, but either they are not detailed enough (you did not provide the exacts scripts to use), or you have a problem that only reproduces on your own machine, or there is some other factor involved here.

I'm marking this bug as Incomplete. If you do find a set of exact, detailed steps that others can follow to reproduce your problem, please detail them in this bug and set the bug status back to New.

You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html, if you're not aware of the information provided there already.

[Ondřej Surý (ondrej)]

I suspect this bugreport is just a result of misunderstanding how the kernel scheduling works (and maybe some draconic VPS settings or not powerful enough CPU).

[KnightMB (knightmb-6)]

Is there a setting that limits php-CLI to only one running instance? I couldn't find any documentation at php.net or a quick google search.

But I can put together some sample code to demonstrate it. My bug report should have been a little more descriptive, but since this is the only distro I've seen it happen in, I wasn't sure how much attention it would get so I waiting for a response first in case it was of no interest or only affected one exact distro.

Ondřej Surý is correct, all the reports I've gotten come from VPS providers. Some of which have a list of dozens of linux distros to try out and this was the only one (I haven't tried all distro versions or arch of Ubuntu, so it may only be limited to this one) But putting together a simple demo should be simple enough.

[KnightMB (knightmb-6)]

3 Files (test1.php, test2.php, test3.php)
I also have the same server with the issue running these live at http://timekoin.gets-it.net/test/
You can test them on the web server this way also.

test1.php just does a 10 second count down.

test3.php does a 10 second count down, but starts at 5 and counts every 2 seconds

test2.php does the same 10 second count down as test1.php, but starts test3.php before doing the count down. The countdown takes 20 seconds because test2.php can not run when test3.php is running. You would see in the console that both are running in memory, but not until test3.php is finished can test2.php complete itself.

Same results if run from the web server or console user.

[Ondřej Surý (ondrej)]

Just don't use bashisms when your default shell is not bash.

The default shell is not interpreting &> as redirection of stdout and stderr, but as background character and runs *two* processes, fist php without redirection and second with empty command (so it probably barfs), but redirected to >/dev/null.

[KnightMB (knightmb-6)]

I ran it in a test user account where the default shell was bash and the problem was still there. No errors produced on screen or logged anywhere.

Anything else I can try?

[KnightMB (knightmb-6)]

If you run

php test3.php &

Runs, gives a process ID, etc. No errors being eaten by /dev/null on the screen or any log file for example.

If you modify test2.php so any errors are easily visible,
change
exec("php test3.php &> /dev/null &");
to
exec("php test3.php &");

Run test2.php again, the problem is still there. Even with correct default shell (in case it wasn't for some reason), the problem still persist.

So while it would be great if the error was a simple as a default shell command mismatch, so far there appears to be no evidence to support this. So I am confused if this is a php-cli issue or not, but so far all evidence points to it.

[Ondřej Surý (ondrej)]

It's not a php-cli bug.

TL;DR
The user (default) shell and default shell (what links from /bin/sh) is two entirely different things. Just don't use '&>', but use '>/dev/null 2>&1' and you'll be fine.

As for:

 exec("php test3.php &");

please go read the exec function documentation.

But you should probably move this to askubuntu.com or any other user support site. This is not a bug in PHP and I am sorry I don't think we should provide user support in the bugreports.

[KnightMB (knightmb-6)]

I appreciate everyone trying to help.

I do know the difference between the two, but your updated example still does not work. It will still freeze the current script until the former script finishes.

The problem appears to be in with php-cli and how it is using the exec function.

I don't expect the devs to fix an bug that exist in php-cli, but so far this bug only exist in Ubuntu and not any other distro that I have tested (arch, redhat, centos, mandriva, mageia, fedora, gentoo, slackware, mint, debian, opensuse, amazon linux,). Yes, I have tested all of those, across many difference versions and arch (32 and 64 bit) The issue has never up until now, but only because others were reporting the issue to me.

So it works in all of those and not in Ubuntu; what is different in Ubuntu?

Again, thanks for all the time and help. I do appreciate the attempts to make it work, I wish I had more time to zero in on what the issue is, but it is beyond my free time at the moment. Thanks again!