#25325 [Opn->Csd]: command from exec do not migrate in an openMosix cluster
ID: 25325
User updated by: carb at videotron dot ca
Reported By: carb at videotron dot ca
-Status: Open
+Status: Closed
Bug Type: Filesystem function related
Operating System: RedHat 9.0
PHP Version: 4.3.3
New Comment:
Running the command with "mosrun -l" removes the lock so that it can
migrate.
/dev/null 2>&1 &");
?>
Previous Comments:
----
[2003-08-30 18:35:21] carb at videotron dot ca
Hi, Thank you for your responses. I fully understand that you do not
work with openMosix.
Yes, there is a cantmove file, but it is empty, meaning that
But is an important issue for anyone who plans to develop a PHP website
that can start processes on an openMosix or any other SSI type cluster.
Since any process that will come fomr php will never migrate, php
could not be used as a front end.
So it would be fun to try to solve this and I am certain that the
openMosix side will also help look at it.
The root of the problem is probably related to the additional stuff
being added to the process when it comes from PHP. Do you have an idea
what this additional (approx.) 600K is?
Yes, the cantmove file is present for all the processes but
unfortunately there are no error messages in it for the processes that
don't migrate.
I will experiment with popen to see if I get different results.
Thanks in advance,
Real
[2003-08-30 17:59:28] [EMAIL PROTECTED]
I don't know openMosix at all (first heard about it now :),
but I read this:
http://howto.ipng.be/openMosix-HOWTO/x1225.html
That first column, about "/proc/$pid/, there often is a cantmove
file..", have you checked that?
Also you should know that we don't fork() with exec() function.
(proc_open() does, maybe you should use that instead?)
----------------
[2003-08-30 16:51:51] carb at videotron dot ca
I think it is related to PHP because that exact command get migrated
correctly when executed from the command line, but does not when it is
executed from PHP/exec().
When starting the process from the command line, the process sizes
are:
SIZE:128, RSS:128, SHARE:40 and it migrates.
When starting the process from PHP/Apache, the process sizes are:
SIZE:736, RSS:732, SHARE:652 and it does NOT migrate.
When starting the process from PHP at the command line, the process
sizes are:
SIZE:740, RSS:732, SHARE:652 and it does NOT migrate.
So we can see that there is alot of extra stuff comming from PHP that
is in the process and it would be this that is affecting the
migration.
openMosix cannot migrate processes that have shared memory, there may
be something like that coming from comming from PHP.
I also posted a message to the openMosix group in case they can help.
https://sourceforge.net/tracker/index.php?func=detail&aid=797919&group_id=46729&atid=447171
Thanks in advance,
Real
[2003-08-30 16:12:41] [EMAIL PROTECTED]
Why do you think this is related to PHP? PHP does *nothing* special
with processes... I wonder how this can be related to OpenMosix.
----------------
[2003-08-30 16:05:16] carb at videotron dot ca
Description:
executing a command from PHP, the command does not get migrated in an
openMosix cluster, even if the command migrates when it is executed
from the command line.
Running "awk 'BEGIN {for(i=0;i<1;i++)for(j=0;j<1;j++);}' >
/dev/null 2>&1 &" from a command line several times creates processes
that get migrated.
Running the same thing several times from an exec in a PHP script does
not get migrated.
The same problem occurs whether the script is executed from apache
"http://localhost/test.php/"; or the command line "php test.php"
Reproduce code:
---
/dev/null 2>&1 &");
?>
Expected result:
When executing the script several times in an openMosix cluster, some
of the processes should migrate.
Actual result:
--
When executing the script several times in an openMosix cluster, none
of the processes migrate.
--
Edit this bug report at http://bugs.php.net/?id=25325&edit=1
#25325 [Fbk->Opn]: command from exec do not migrate in an openMosix cluster
ID: 25325
User updated by: carb at videotron dot ca
Reported By: carb at videotron dot ca
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: RedHat 9.0
PHP Version: 4.3.3
New Comment:
Hi, Thank you for your responses. I fully understand that you do not
work with openMosix.
Yes, there is a cantmove file, but it is empty, meaning that
But is an important issue for anyone who plans to develop a PHP website
that can start processes on an openMosix or any other SSI type cluster.
Since any process that will come fomr php will never migrate, php
could not be used as a front end.
So it would be fun to try to solve this and I am certain that the
openMosix side will also help look at it.
The root of the problem is probably related to the additional stuff
being added to the process when it comes from PHP. Do you have an idea
what this additional (approx.) 600K is?
Yes, the cantmove file is present for all the processes but
unfortunately there are no error messages in it for the processes that
don't migrate.
I will experiment with popen to see if I get different results.
Thanks in advance,
Real
Previous Comments:
[2003-08-30 17:59:28] [EMAIL PROTECTED]
I don't know openMosix at all (first heard about it now :),
but I read this:
http://howto.ipng.be/openMosix-HOWTO/x1225.html
That first column, about "/proc/$pid/, there often is a cantmove
file..", have you checked that?
Also you should know that we don't fork() with exec() function.
(proc_open() does, maybe you should use that instead?)
----
[2003-08-30 16:51:51] carb at videotron dot ca
I think it is related to PHP because that exact command get migrated
correctly when executed from the command line, but does not when it is
executed from PHP/exec().
When starting the process from the command line, the process sizes
are:
SIZE:128, RSS:128, SHARE:40 and it migrates.
When starting the process from PHP/Apache, the process sizes are:
SIZE:736, RSS:732, SHARE:652 and it does NOT migrate.
When starting the process from PHP at the command line, the process
sizes are:
SIZE:740, RSS:732, SHARE:652 and it does NOT migrate.
So we can see that there is alot of extra stuff comming from PHP that
is in the process and it would be this that is affecting the
migration.
openMosix cannot migrate processes that have shared memory, there may
be something like that coming from comming from PHP.
I also posted a message to the openMosix group in case they can help.
https://sourceforge.net/tracker/index.php?func=detail&aid=797919&group_id=46729&atid=447171
Thanks in advance,
Real
[2003-08-30 16:12:41] [EMAIL PROTECTED]
Why do you think this is related to PHP? PHP does *nothing* special
with processes... I wonder how this can be related to OpenMosix.
--------
[2003-08-30 16:05:16] carb at videotron dot ca
Description:
executing a command from PHP, the command does not get migrated in an
openMosix cluster, even if the command migrates when it is executed
from the command line.
Running "awk 'BEGIN {for(i=0;i<1;i++)for(j=0;j<1;j++);}' >
/dev/null 2>&1 &" from a command line several times creates processes
that get migrated.
Running the same thing several times from an exec in a PHP script does
not get migrated.
The same problem occurs whether the script is executed from apache
"http://localhost/test.php/"; or the command line "php test.php"
Reproduce code:
---
/dev/null 2>&1 &");
?>
Expected result:
When executing the script several times in an openMosix cluster, some
of the processes should migrate.
Actual result:
--
When executing the script several times in an openMosix cluster, none
of the processes migrate.
--
Edit this bug report at http://bugs.php.net/?id=25325&edit=1
#25325 [Fbk->Opn]: command from exec do not migrate in an openMosix cluster
ID: 25325
User updated by: carb at videotron dot ca
Reported By: carb at videotron dot ca
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: RedHat 9.0
PHP Version: 4.3.3
New Comment:
I think it is related to PHP because that exact command get migrated
correctly when executed from the command line, but does not when it is
executed from PHP/exec().
When starting the process from the command line, the process sizes
are:
SIZE:128, RSS:128, SHARE:40 and it migrates.
When starting the process from PHP/Apache, the process sizes are:
SIZE:736, RSS:732, SHARE:652 and it does NOT migrate.
When starting the process from PHP at the command line, the process
sizes are:
SIZE:740, RSS:732, SHARE:652 and it does NOT migrate.
So we can see that there is alot of extra stuff comming from PHP that
is in the process and it would be this that is affecting the
migration.
openMosix cannot migrate processes that have shared memory, there may
be something like that coming from comming from PHP.
I also posted a message to the openMosix group in case they can help.
https://sourceforge.net/tracker/index.php?func=detail&aid=797919&group_id=46729&atid=447171
Thanks in advance,
Real
Previous Comments:
[2003-08-30 16:12:41] [EMAIL PROTECTED]
Why do you think this is related to PHP? PHP does *nothing* special
with processes... I wonder how this can be related to OpenMosix.
[2003-08-30 16:08:02] [EMAIL PROTECTED]
Sorry,
I did not meant to do that.
[2003-08-30 16:07:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-08-30 16:05:16] carb at videotron dot ca
Description:
executing a command from PHP, the command does not get migrated in an
openMosix cluster, even if the command migrates when it is executed
from the command line.
Running "awk 'BEGIN {for(i=0;i<1;i++)for(j=0;j<1;j++);}' >
/dev/null 2>&1 &" from a command line several times creates processes
that get migrated.
Running the same thing several times from an exec in a PHP script does
not get migrated.
The same problem occurs whether the script is executed from apache
"http://localhost/test.php/"; or the command line "php test.php"
Reproduce code:
---
/dev/null 2>&1 &");
?>
Expected result:
When executing the script several times in an openMosix cluster, some
of the processes should migrate.
Actual result:
--
When executing the script several times in an openMosix cluster, none
of the processes migrate.
--
Edit this bug report at http://bugs.php.net/?id=25325&edit=1
#25325 [NEW]: command from exec do not migrate in an openMosix cluster
From: carb at videotron dot ca
Operating system: RedHat 9.0
PHP version: 4.3.3
PHP Bug Type: Filesystem function related
Bug description: command from exec do not migrate in an openMosix cluster
Description:
executing a command from PHP, the command does not get migrated in an
openMosix cluster, even if the command migrates when it is executed from
the command line.
Running "awk 'BEGIN {for(i=0;i<1;i++)for(j=0;j<1;j++);}' >
/dev/null 2>&1 &" from a command line several times creates processes that
get migrated.
Running the same thing several times from an exec in a PHP script does not
get migrated.
The same problem occurs whether the script is executed from apache
"http://localhost/test.php/"; or the command line "php test.php"
Reproduce code:
---
/dev/null 2>&1 &");
?>
Expected result:
When executing the script several times in an openMosix cluster, some of
the processes should migrate.
Actual result:
--
When executing the script several times in an openMosix cluster, none of
the processes migrate.
--
Edit bug report at http://bugs.php.net/?id=25325&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25325&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25325&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25325&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25325&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25325&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25325&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25325&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25325&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25325&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25325&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25325&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25325&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25325&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25325&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25325&r=gnused
#24616 [Bgs->Opn]: Process started with "exec cmd > /dev/null &" dies when httpd is closed
ID: 24616
User updated by: carb at videotron dot ca
Reported By: carb at videotron dot ca
-Status: Bogus
+Status: Open
Bug Type: Apache related
Operating System: RedHat 9.0
PHP Version: 4.3.2
New Comment:
Ok, that bug is informative, but why not fork off child processes as
completely seperate from httpd so that they can really run in the
background seperately from the parent? Such as a double fork to ophan
off the process.
I don't think that people who forks off a background process from
httpd/php with the "&" expect it to die if/when httpd happens to be
restarted or closed.
Real
Previous Comments:
[2003-07-13 00:02:43] [EMAIL PROTECTED]
This is a feature, not bug. (look in bug #15529 for another
perpective.. :)
[2003-07-12 01:07:27] carb at videotron dot ca
Same behavior with:
/dev/null 2>/dev/null &");
?>
--------
[2003-07-12 01:00:33] carb at videotron dot ca
Description:
When forking off a process from PHP with the statement exec("command >
/dev/null &"), the process will get killed when the httpd is closed.
Note: This occurs even though ps is telling me that the parent process
id is init (parent process id 1).
Reproduce code:
---
/dev/null &");
?>
Expected result:
A continuous ping process should be running in the backgroud,
independently of httpd. When httpd is closed, the ping (or whatever
relevant) process should keep running.
Actual result:
--
When httpd is closed, the ping (or whatever relevant) process dies.
--
Edit this bug report at http://bugs.php.net/?id=24616&edit=1
#24616 [Opn]: Process started with "exec cmd > /dev/null &" dies when httpd is closed
ID: 24616
User updated by: carb at videotron dot ca
Reported By: carb at videotron dot ca
Status: Open
Bug Type: Apache related
Operating System: RedHat 9.0
PHP Version: 4.3.2
New Comment:
Same behavior with:
/dev/null 2>/dev/null &");
?>
Previous Comments:
[2003-07-12 01:00:33] carb at videotron dot ca
Description:
When forking off a process from PHP with the statement exec("command >
/dev/null &"), the process will get killed when the httpd is closed.
Note: This occurs even though ps is telling me that the parent process
id is init (parent process id 1).
Reproduce code:
---
/dev/null &");
?>
Expected result:
A continuous ping process should be running in the backgroud,
independently of httpd. When httpd is closed, the ping (or whatever
relevant) process should keep running.
Actual result:
--
When httpd is closed, the ping (or whatever relevant) process dies.
--
Edit this bug report at http://bugs.php.net/?id=24616&edit=1
#24616 [NEW]: Process started with "exec cmd > /dev/null &" dies when httpd is closed
From: carb at videotron dot ca
Operating system: RedHat 9.0
PHP version: 4.3.2
PHP Bug Type: Apache related
Bug description: Process started with "exec cmd > /dev/null &" dies when httpd is
closed
Description:
When forking off a process from PHP with the statement exec("command >
/dev/null &"), the process will get killed when the httpd is closed.
Note: This occurs even though ps is telling me that the parent process id
is init (parent process id 1).
Reproduce code:
---
/dev/null &");
?>
Expected result:
A continuous ping process should be running in the backgroud,
independently of httpd. When httpd is closed, the ping (or whatever
relevant) process should keep running.
Actual result:
--
When httpd is closed, the ping (or whatever relevant) process dies.
--
Edit bug report at http://bugs.php.net/?id=24616&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24616&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24616&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24616&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24616&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24616&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24616&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24616&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24616&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24616&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24616&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24616&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24616&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24616&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24616&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24616&r=gnused
