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
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).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
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
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
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
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?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in
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
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 21' and
you'll be fine.
As for:
exec(php test3.php );
please go read the exec function documentation.
But you should
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
