background - "stopped" how to kill!

[bruce]

Hi.

I know this isn't really a fed issue, but I'm curious to how to handle it.

I have a basic test php app foo.php

I run it from the cmdline - it sleeps, it dies, life is good. The pID
is removed from the procTBL as expected.

However, if I change the running to be -- foo.php & so the test runs
as a background process, the process gets listed as "Stopped" "T" in
the status of the procTBL.

My question, is how the heck can I implement something within the test
foo.php to have it die/be removed from the procTBL when it dies..

I've implemented the kill_posix within the app, and I've searched alla
over trying to resolve this..

So, what the heck am I missing.

And I know I could have an external app kill it, but that's the same
as killing the foo.php test from the cmdline..

Thoughts/comments..

thanks

[Garry Williams]

On 6-6-14 13:44:51 bruce wrote:
>  However, if I change the running to be -- foo.php & so the test
> runs
>  as a background process, the process gets listed as "Stopped" "T" in
>  the status of the procTBL. 
T means the process received a SIGSTOP signal.  Send the process a
SIGCONT signal, then a SIGTERM signal:

    kill -CONT <pid>
    kill <pid>

-- 
Garry T. Williams

[Cameron Simpson]

On 06Jun2014 13:17, Rick Stevens <ricks(a)alldigital.com&gt; wrote:
> >As you can see, there's nothing special about this. And yeah,
> when
> >runs as foo.php & <<  it shows up in the procTBL as "T" in the
> status.
> >
> >There are no filedescriptors in the test.
>
> It has at least one descriptor, stdout. You're having it print two
> lines. If you background it, it's going to hang trying to print out to
> stdout.
>
> Try "php foo.php >/dev/null 2>&1 &" to make it write stdout and
> stderr
> to /dev/null and see if that works. 
Normally a background process can write to the tty. IIRC, that might be 
tunable. More common is to stop when it reads from the tty. Eg:

   % read it &
   [1] 71654
   [1]  + 71654 suspended (tty input)  read it
   %

That's zsh. Bash does the same thing but looks like this:

   % read it&
   [1] 72595
   [1]+  Stopped(SIGTTIN)        read it
   %

The other thing to try it strace. Look up the PID of your process. (Suppose it 
is 13.) Then:

   strace -p 13

The should tell you what system call it was making when it was suspended, and 
what file descriptors were involved.

Cheers,
Cameron Simpson <cs(a)zip.com.au&gt;

It is easier to optimize correct code than to correct optimized code.
- Bill Harlan

[Rick Stevens]

On 06/06/2014 11:08 AM, bruce issued this missive:
>  Hi Russell,
>
>  the test code is::
>  #!/usr/bin/php
>  <?php
>  /*
>
>       parent.php
>
>       /ycrawl/dcrawl/run/yolo-master/parent.php
>
>       test to see about the "&" background process
>  */
>
>  print "start \n";
>  sleep(5);
>
>  print "stop \n";
>
>  $t=posix_getpid();
>  //system("kill -9 ".$t);
>  posix_kill($t, 9);
>  exit();
>
>  ?>
>
>
>  As you can see, there's nothing special about this. And yeah, when
>  runs as foo.php & <<  it shows up in the procTBL as "T" in the
> status.
>
>  There are no filedescriptors in the test. 
It has at least one descriptor, stdout. You're having it print two
lines. If you background it, it's going to hang trying to print out to
stdout.

Try "php foo.php >/dev/null 2>&1 &" to make it write stdout and
stderr
to /dev/null and see if that works.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks(a)alldigital.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
- Grabel's Law: 2 is not equal to 3--not even for large values of 2. -
----------------------------------------------------------------------

[bruce]

Hi Russell,

the test code is::
#!/usr/bin/php
<?php
/*

    parent.php

    /ycrawl/dcrawl/run/yolo-master/parent.php

    test to see about the "&" background process
*/

print "start \n";
sleep(5);

print "stop \n";

$t=posix_getpid();
//system("kill -9 ".$t);
posix_kill($t, 9);
exit();

?>


As you can see, there's nothing special about this. And yeah, when
runs as foo.php & <<  it shows up in the procTBL as "T" in the
status.

There are no filedescriptors in the test.






On Fri, Jun 6, 2014 at 1:48 PM, Russell Miller <duskglow(a)gmail.com&gt; wrote:
>  On Jun 6, 2014, at 10:44 AM, bruce <badouglas(a)gmail.com&gt; wrote:
> >
> > My question, is how the heck can I implement something within the test
> > foo.php to have it die/be removed from the procTBL when it dies..
>
>  If it's "stopped" that means it's not running, it's probably got an
> fd to the tty open
>  and is listening for input.  Not designed to run in the background.
>
>  "kill %1" might work to kill it.
>
>  --Russell
>  --
>  users mailing list
>  users(a)lists.fedoraproject.org
>  To unsubscribe or change subscription options:
>  https://admin.fedoraproject.org/mailman/listinfo/users
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>  Have a question? Ask away: http://ask.fedoraproject.org

[Russell Miller]

On Jun 6, 2014, at 10:44 AM, bruce <badouglas(a)gmail.com&gt; wrote:
>  
>  My question, is how the heck can I implement something within the test
>  foo.php to have it die/be removed from the procTBL when it dies.. 
If it's "stopped" that means it's not running, it's probably got an
fd to the tty open
and is listening for input.  Not designed to run in the background.

"kill %1" might work to kill it.

--Russell