[Xenomai] Children of forked process do not die upon receiving SIGKILL in Xenomai?

[Xenomai] Children of forked process do not die upon receiving SIGKILL in Xenomai?

[Soo-Hyun Yoo]

Hello,

I have a certain process "A" that forks and execs a process "B". B
spawns multiple child processes.

In the vanilla Linux kernel, I can have A send a SIGTERM or SIGKILL to
B and thereby successfully kill B and all of its children.

Under Xenomai, however, I am noticing that the same action kills B,
but B's children make init their new parent and continue running.

Why is this, and what can I do to kill B's children without having to
use a script to track down each child process individually?

Thank you.

Soo-Hyun Yoo
Dynamic Robotics Laboratory
Oregon State University

Re: [Xenomai] Children of forked process do not die upon receiving SIGKILL in Xenomai?

[Gilles Chanteperdrix]

On 09/11/2012 06:22 PM, Soo-Hyun Yoo wrote:
> Hello,
> 
> I have a certain process "A" that forks and execs a process "B". B
> spawns multiple child processes.
> 
> In the vanilla Linux kernel, I can have A send a SIGTERM or SIGKILL to
> B and thereby successfully kill B and all of its children.
> 
> Under Xenomai, however, I am noticing that the same action kills B,
> but B's children make init their new parent and continue running.
> 
> Why is this, and what can I do to kill B's children without having to
> use a script to track down each child process individually?

No idea, please send a test case allowing us to reproduce the issue.

-- 
					    Gilles.

Re: [Xenomai] Children of forked process do not die upon receiving SIGKILL in Xenomai?

[Christophe Blaess]

Le 11/09/2012 18:25, Gilles Chanteperdrix a écrit :
> On 09/11/2012 06:22 PM, Soo-Hyun Yoo wrote:
>> Hello,
>>
>> I have a certain process "A" that forks and execs a process "B". B
>> spawns multiple child processes.
>>
>> In the vanilla Linux kernel, I can have A send a SIGTERM or SIGKILL to
>> B and thereby successfully kill B and all of its children.
No, the childs of B remain alive. Try this code.

*test-kill.c*

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
     pid_t pid;

     fprintf(stderr, "[%d] I'm A\n", getpid());
     if ((pid = fork()) == 0) {
         fprintf(stderr, "[%d] I'm B\n", getpid());
        if (fork() == 0) {
             while (1) {
                 fprintf(stderr, "[%d] I'm C\n", getpid());
                 sleep(1);
             }
         } else {
             while (1) {
                 fprintf(stderr, "[%d] I'm B\n", getpid());
                 sleep(1);
             }
         }
     }
     sleep(3);
     fprintf(stderr,"A kills B\n");
     kill(pid, 9);
     fprintf(stderr, "and A exits\n");
     exit(0);
}


And you'll see :

$ ./test-kill
[15925] I'm A
[15926] I'm B
[15926] I'm B
[15927] I'm C
[15926] I'm B
[15927] I'm C
[15926] I'm B
[15927] I'm C
A kills B
and A exits
$ [15927] I'm C
[15927] I'm C
[15927] I'm C
[15927] I'm C
[15927] I'm C
[15927] I'm C
[15927] I'm C

To kill B's childs, you need to send the signal to the group of processes.

Re: [Xenomai] Children of forked process do not die upon receiving SIGKILL in Xenomai?

[Soo-Hyun Yoo]

On Tue, Sep 11, 2012 at 9:53 AM, Christophe Blaess <mailist@logilin.fr> wrote:
> Le 11/09/2012 18:25, Gilles Chanteperdrix a écrit :
>
>> On 09/11/2012 06:22 PM, Soo-Hyun Yoo wrote:
>>>
>>> Hello,
>>>
>>> I have a certain process "A" that forks and execs a process "B". B
>>> spawns multiple child processes.
>>>
>>> In the vanilla Linux kernel, I can have A send a SIGTERM or SIGKILL to
>>> B and thereby successfully kill B and all of its children.
>
> No, the childs of B remain alive. Try this code.
>
> *test-kill.c*
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> int main(void)
> {
>     pid_t pid;
>
>     fprintf(stderr, "[%d] I'm A\n", getpid());
>     if ((pid = fork()) == 0) {
>         fprintf(stderr, "[%d] I'm B\n", getpid());
>        if (fork() == 0) {
>             while (1) {
>                 fprintf(stderr, "[%d] I'm C\n", getpid());
>                 sleep(1);
>             }
>         } else {
>             while (1) {
>                 fprintf(stderr, "[%d] I'm B\n", getpid());
>                 sleep(1);
>             }
>         }
>     }
>     sleep(3);
>     fprintf(stderr,"A kills B\n");
>     kill(pid, 9);
>     fprintf(stderr, "and A exits\n");
>     exit(0);
> }
>
>
> And you'll see :
>
> $ ./test-kill
> [15925] I'm A
> [15926] I'm B
> [15926] I'm B
> [15927] I'm C
> [15926] I'm B
> [15927] I'm C
> [15926] I'm B
> [15927] I'm C
> A kills B
> and A exits
> $ [15927] I'm C
> [15927] I'm C
> [15927] I'm C
> [15927] I'm C
> [15927] I'm C
> [15927] I'm C
> [15927] I'm C
>
> To kill B's childs, you need to send the signal to the group of processes.

I see I had misunderstood the way in which processes work. Thank you
for the code. Apparently, I also did not test this as thoroughly as I
thought I had.

What really is a problem is that Robot Operating System's rosbag (our
process B) does not die properly upon receiving a SIGINT in Xenomai
(whereas it does in vanilla Linux) and instead gets stuck at 100% CPU
core usage in a few of its threads. This is what led me to 4 hours of
fumbling around with other signal types. This, however, is a different
problem that is probably more related to ROS, so I will ask on their
mailing list.

Soo-Hyun Yoo

>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Children of forked process do not die upon receiving SIGKILL in Xenomai?

[Gilles Chanteperdrix]

On 09/11/2012 08:27 PM, Soo-Hyun Yoo wrote:

> On Tue, Sep 11, 2012 at 9:53 AM, Christophe Blaess <mailist@logilin.fr> wrote:
>> Le 11/09/2012 18:25, Gilles Chanteperdrix a écrit :
>>
>>> On 09/11/2012 06:22 PM, Soo-Hyun Yoo wrote:
>>>>
>>>> Hello,
>>>>
>>>> I have a certain process "A" that forks and execs a process "B". B
>>>> spawns multiple child processes.
>>>>
>>>> In the vanilla Linux kernel, I can have A send a SIGTERM or SIGKILL to
>>>> B and thereby successfully kill B and all of its children.
>>
>> No, the childs of B remain alive. Try this code.
>>
>> *test-kill.c*
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <unistd.h>
>>
>> int main(void)
>> {
>>     pid_t pid;
>>
>>     fprintf(stderr, "[%d] I'm A\n", getpid());
>>     if ((pid = fork()) == 0) {
>>         fprintf(stderr, "[%d] I'm B\n", getpid());
>>        if (fork() == 0) {
>>             while (1) {
>>                 fprintf(stderr, "[%d] I'm C\n", getpid());
>>                 sleep(1);
>>             }
>>         } else {
>>             while (1) {
>>                 fprintf(stderr, "[%d] I'm B\n", getpid());
>>                 sleep(1);
>>             }
>>         }
>>     }
>>     sleep(3);
>>     fprintf(stderr,"A kills B\n");
>>     kill(pid, 9);
>>     fprintf(stderr, "and A exits\n");
>>     exit(0);
>> }
>>
>>
>> And you'll see :
>>
>> $ ./test-kill
>> [15925] I'm A
>> [15926] I'm B
>> [15926] I'm B
>> [15927] I'm C
>> [15926] I'm B
>> [15927] I'm C
>> [15926] I'm B
>> [15927] I'm C
>> A kills B
>> and A exits
>> $ [15927] I'm C
>> [15927] I'm C
>> [15927] I'm C
>> [15927] I'm C
>> [15927] I'm C
>> [15927] I'm C
>> [15927] I'm C
>>
>> To kill B's childs, you need to send the signal to the group of processes.
> 
> I see I had misunderstood the way in which processes work. Thank you
> for the code. Apparently, I also did not test this as thoroughly as I
> thought I had.
> 
> What really is a problem is that Robot Operating System's rosbag (our
> process B) does not die properly upon receiving a SIGINT in Xenomai
> (whereas it does in vanilla Linux) and instead gets stuck at 100% CPU
> core usage in a few of its threads. This is what led me to 4 hours of
> fumbling around with other signal types. This, however, is a different
> problem that is probably more related to ROS, so I will ask on their
> mailing list.


If you can connect gdb to the remaining process, debugging this is
should be easy. One difference between Xenomai and plain linux processes
is that Xenomai spawns a thread for handling the printfs from primary
mode, so, you can not exit the main thread with pthread_exit any longer,
you have to exit it with exit.

-- 
                                                                Gilles.