On Wed, 21 Jul 2004 13:55:37 -0500, Michael Sims
<[EMAIL PROTECTED]> wrote:
> Michael Sims wrote:
> > Justin Patrin wrote:
> >> On Wed, 21 Jul 2004 10:09:52 -0700, bruce <[EMAIL PROTECTED]>
> >> 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?
--
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder
paperCrane --Justin Patrin--
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
