Re: exec/system question..

Justin Patrin wrote:

On Wed, 21 Jul 2004 13:55:37 -0500, Michael Sims <michaels@crye-leike.com> wrote:

Michael Sims wrote:

Justin Patrin wrote:

On Wed, 21 Jul 2004 10:09:52 -0700, bruce <bedouglas@earthlink.net> wrote:

2) i could run the perl script, and have it somehow run in the background.... this would ba good, if there's a way to essentially

[...]

AFAIK there's no way to do this. When the request ends (user hits stop, exit or die called) the process is ended. This includes children.

There are ways around that, though, at least if you're running unix: exec('bash -c "exec nohup setsid your_command > /dev/null 2>&1 &"');

Sorry to followup to my own post, but I just did some quick testing and apparently none of the above (nohup, setsid) is really necessary. As long as the output of the command is redirected somewhere and the "&" is used to start it in the background it will continue to run even if the process that launched it exits or is killed. I tested this with the following (named 'test.php'): --- #!/usr/local/bin/php <? if (isset($argv[1])) { exec('./test.php > /dev/null &'); } sleep(10); exec('wall testing - ignore '.getmypid()); ?> --- I opened two SSH sessions, ran the above script in one (using './test.php 1') then immediately exited the SSH session. The PHP processes (both of them) continued to execute and I saw the "wall" output from both scripts in my other SSH session. So apparently the nohup setsid stuff is overkill...

Did you try it from the web? Just to be devil's advocate and be sure that, say, clicking Stop doesn't stop the background process. Also, does *killing* the original script kill the child?

It's a well-understood technique; I have used it quite a bit--mostly in web-based scripts. If you like, you can even redirect your output to a file instead of /dev/null, and put a refresh on the calling page which checks that file, providing a progress update on each reload. Hope this helps, Torben <torben@php.net>