[Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Kim De Mey]

Hello all,

I noticed that when enabling the registry in Xenomai-forge (mercury
core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
spawn_daemon() call.
I guess this choice was made to make sure no zombies of the daemon
stay alive. Correct?

This does however mean that the default behaviour of the application
regarding the handling of children is changed. Now I wonder whether it
is okay (as a rule/practice) for a library to change this behaviour of
the application. Shouldn't we look for a solution where the behaviour
of the application remains untouched?

Regards,
Kim

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Philippe Gerum]

On 02/25/2014 10:07 AM, Kim De Mey wrote:
> Hello all,
>
> I noticed that when enabling the registry in Xenomai-forge (mercury
> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
> spawn_daemon() call.
> I guess this choice was made to make sure no zombies of the daemon
> stay alive. Correct?

Yes.

>
> This does however mean that the default behaviour of the application
> regarding the handling of children is changed. Now I wonder whether it
> is okay (as a rule/practice) for a library to change this behaviour of
> the application. Shouldn't we look for a solution where the behaviour
> of the application remains untouched?
>

The default action for SIGCHLD is to ignore it. If the app wants to 
handle this signal specifically, it will have to trap it and figure out 
which child it cares about has exited in any case. So the library action 
for this signal does not change anything to the default case actually.

-- 
Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Kim De Mey]

2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>
>> Hello all,
>>
>> I noticed that when enabling the registry in Xenomai-forge (mercury
>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>> spawn_daemon() call.
>> I guess this choice was made to make sure no zombies of the daemon
>> stay alive. Correct?
>
>
> Yes.
>
>
>>
>> This does however mean that the default behaviour of the application
>> regarding the handling of children is changed. Now I wonder whether it
>> is okay (as a rule/practice) for a library to change this behaviour of
>> the application. Shouldn't we look for a solution where the behaviour
>> of the application remains untouched?
>>
>
> The default action for SIGCHLD is to ignore it. If the app wants to handle
> this signal specifically, it will have to trap it and figure out which child
> it cares about has exited in any case. So the library action for this signal
> does not change anything to the default case actually.
>

It is true that the default is to ignore it. However setting the
action explicitly to ignore does change the termination behaviour of
children. The children that terminate will no longer become zombies
and behaviour of wait() and wait_pid() calls is thus different (see
man page of waitpid()).
This different behaviour of waitpid() is also how I noticed the SIG_IGN.

> --
> Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Philippe Gerum]

On 02/25/2014 08:03 PM, Kim De Mey wrote:
> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>
>>> Hello all,
>>>
>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>> spawn_daemon() call.
>>> I guess this choice was made to make sure no zombies of the daemon
>>> stay alive. Correct?
>>
>>
>> Yes.
>>
>>
>>>
>>> This does however mean that the default behaviour of the application
>>> regarding the handling of children is changed. Now I wonder whether it
>>> is okay (as a rule/practice) for a library to change this behaviour of
>>> the application. Shouldn't we look for a solution where the behaviour
>>> of the application remains untouched?
>>>
>>
>> The default action for SIGCHLD is to ignore it. If the app wants to handle
>> this signal specifically, it will have to trap it and figure out which child
>> it cares about has exited in any case. So the library action for this signal
>> does not change anything to the default case actually.
>>
>
> It is true that the default is to ignore it. However setting the
> action explicitly to ignore does change the termination behaviour of
> children. The children that terminate will no longer become zombies
> and behaviour of wait() and wait_pid() calls is thus different (see
> man page of waitpid()).
> This different behaviour of waitpid() is also how I noticed the SIG_IGN.
>

Which does not change the situation with respect to handling SIGCLD, 
only for background threads calling waitpid() to collect exit statuses 
eagerly, in absence of exit notification.

Your application can still re-trap SIGCLD to some handler, do the wait() 
to collect the exit status there, identifying your own threads based on 
the returned pid to take proper action. In that sense, the fact that the 
library initially ignores the signal does not change the general 
behavior if you do care for such signal afterwards.

The issue in your case seems that you don't want to set any disposition 
for SIGCLD, and therefore expect that copperplate won't do it either. So 
the alternative for preventing zombies is between trusting the 
application for collecting all statuses properly, or asking the 
application to use the signal-based mechanism for collecting exit 
status. Option #2 is current, as you noticed it.

-- 
Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Kim De Mey]

2014-02-26 10:26 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
> On 02/25/2014 08:03 PM, Kim De Mey wrote:
>>
>> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>
>>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>>
>>>>
>>>> Hello all,
>>>>
>>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>>> spawn_daemon() call.
>>>> I guess this choice was made to make sure no zombies of the daemon
>>>> stay alive. Correct?
>>>
>>>
>>>
>>> Yes.
>>>
>>>
>>>>
>>>> This does however mean that the default behaviour of the application
>>>> regarding the handling of children is changed. Now I wonder whether it
>>>> is okay (as a rule/practice) for a library to change this behaviour of
>>>> the application. Shouldn't we look for a solution where the behaviour
>>>> of the application remains untouched?
>>>>
>>>
>>> The default action for SIGCHLD is to ignore it. If the app wants to
>>> handle
>>> this signal specifically, it will have to trap it and figure out which
>>> child
>>> it cares about has exited in any case. So the library action for this
>>> signal
>>> does not change anything to the default case actually.
>>>
>>
>> It is true that the default is to ignore it. However setting the
>> action explicitly to ignore does change the termination behaviour of
>> children. The children that terminate will no longer become zombies
>> and behaviour of wait() and wait_pid() calls is thus different (see
>> man page of waitpid()).
>> This different behaviour of waitpid() is also how I noticed the SIG_IGN.
>>
>
> Which does not change the situation with respect to handling SIGCLD, only
> for background threads calling waitpid() to collect exit statuses eagerly,
> in absence of exit notification.
>
> Your application can still re-trap SIGCLD to some handler, do the wait() to
> collect the exit status there, identifying your own threads based on the
> returned pid to take proper action. In that sense, the fact that the library
> initially ignores the signal does not change the general behavior if you do
> care for such signal afterwards.
>
> The issue in your case seems that you don't want to set any disposition for
> SIGCLD, and therefore expect that copperplate won't do it either. So the
> alternative for preventing zombies is between trusting the application for
> collecting all statuses properly, or asking the application to use the
> signal-based mechanism for collecting exit status. Option #2 is current, as
> you noticed it.

I understand this reasoning and the fact that you can't trust the
application to handle all the zombies and thus your choice for option
#2. However I was just hoping there was an option #3 where the library
does leave the behaviour of the application as is and can handle the
daemon exit itself somehow.

As you might have guessed, our application does not use a signal-based
mechanism to collect the child exit status but does it sequentially
with waitpid after the forking (we need to wait for the child to end
anyway). Hence the issue.

Also If I understand it right, it means that if you then do install a
signal handler, you have to make sure that you also handle the Xenomai
daemon exit correct. Which then again puts thrust within the
application, although the application developer might not even realize
this if a signal handler was already used in the first place.

>
> --
> Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Philippe Gerum]

On 02/27/2014 08:36 AM, Kim De Mey wrote:
> 2014-02-26 10:26 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>> On 02/25/2014 08:03 PM, Kim De Mey wrote:
>>>
>>> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>
>>>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>>>
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>>>> spawn_daemon() call.
>>>>> I guess this choice was made to make sure no zombies of the daemon
>>>>> stay alive. Correct?
>>>>
>>>>
>>>>
>>>> Yes.
>>>>
>>>>
>>>>>
>>>>> This does however mean that the default behaviour of the application
>>>>> regarding the handling of children is changed. Now I wonder whether it
>>>>> is okay (as a rule/practice) for a library to change this behaviour of
>>>>> the application. Shouldn't we look for a solution where the behaviour
>>>>> of the application remains untouched?
>>>>>
>>>>
>>>> The default action for SIGCHLD is to ignore it. If the app wants to
>>>> handle
>>>> this signal specifically, it will have to trap it and figure out which
>>>> child
>>>> it cares about has exited in any case. So the library action for this
>>>> signal
>>>> does not change anything to the default case actually.
>>>>
>>>
>>> It is true that the default is to ignore it. However setting the
>>> action explicitly to ignore does change the termination behaviour of
>>> children. The children that terminate will no longer become zombies
>>> and behaviour of wait() and wait_pid() calls is thus different (see
>>> man page of waitpid()).
>>> This different behaviour of waitpid() is also how I noticed the SIG_IGN.
>>>
>>
>> Which does not change the situation with respect to handling SIGCLD, only
>> for background threads calling waitpid() to collect exit statuses eagerly,
>> in absence of exit notification.
>>
>> Your application can still re-trap SIGCLD to some handler, do the wait() to
>> collect the exit status there, identifying your own threads based on the
>> returned pid to take proper action. In that sense, the fact that the library
>> initially ignores the signal does not change the general behavior if you do
>> care for such signal afterwards.
>>
>> The issue in your case seems that you don't want to set any disposition for
>> SIGCLD, and therefore expect that copperplate won't do it either. So the
>> alternative for preventing zombies is between trusting the application for
>> collecting all statuses properly, or asking the application to use the
>> signal-based mechanism for collecting exit status. Option #2 is current, as
>> you noticed it.
>
> I understand this reasoning and the fact that you can't trust the
> application to handle all the zombies and thus your choice for option
> #2. However I was just hoping there was an option #3 where the library
> does leave the behaviour of the application as is and can handle the
> daemon exit itself somehow.

There is a simpler option: the library could install a valid handler 
instead of SIG_IGN, which the application could override. Whether the 
application does install its own handler or only copperplate does, 
zombies would be prevented. I'll push something along these lines.

>
> As you might have guessed, our application does not use a signal-based
> mechanism to collect the child exit status but does it sequentially
> with waitpid after the forking (we need to wait for the child to end
> anyway). Hence the issue.
>
> Also If I understand it right, it means that if you then do install a
> signal handler, you have to make sure that you also handle the Xenomai
> daemon exit correct. Which then again puts thrust within the
> application, although the application developer might not even realize
> this if a signal handler was already used in the first place.
>

As the application installs a valid handler for dealing with its own 
children, it implicitly registers for receiving regd exit notification, 
preventing zombies. If it does not install any handler, the library did 
so earlier though, so problem gone the same way. In other words, by 
trapping SIGCHLD, the application already does the job of preventing 
zombies implicitly.

The bogus case would be that no one within the parent process - either 
copperplate or the application code - installs a handler for SIGCHLD, 
either valid or SIG_IGN, it does not matter.

-- 
Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Philippe Gerum]

On 02/27/2014 10:50 AM, Philippe Gerum wrote:
> On 02/27/2014 08:36 AM, Kim De Mey wrote:
>> 2014-02-26 10:26 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>> On 02/25/2014 08:03 PM, Kim De Mey wrote:
>>>>
>>>> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>
>>>>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>>>>
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>>>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>>>>> spawn_daemon() call.
>>>>>> I guess this choice was made to make sure no zombies of the daemon
>>>>>> stay alive. Correct?
>>>>>
>>>>>
>>>>>
>>>>> Yes.
>>>>>
>>>>>
>>>>>>
>>>>>> This does however mean that the default behaviour of the application
>>>>>> regarding the handling of children is changed. Now I wonder
>>>>>> whether it
>>>>>> is okay (as a rule/practice) for a library to change this
>>>>>> behaviour of
>>>>>> the application. Shouldn't we look for a solution where the behaviour
>>>>>> of the application remains untouched?
>>>>>>
>>>>>
>>>>> The default action for SIGCHLD is to ignore it. If the app wants to
>>>>> handle
>>>>> this signal specifically, it will have to trap it and figure out which
>>>>> child
>>>>> it cares about has exited in any case. So the library action for this
>>>>> signal
>>>>> does not change anything to the default case actually.
>>>>>
>>>>
>>>> It is true that the default is to ignore it. However setting the
>>>> action explicitly to ignore does change the termination behaviour of
>>>> children. The children that terminate will no longer become zombies
>>>> and behaviour of wait() and wait_pid() calls is thus different (see
>>>> man page of waitpid()).
>>>> This different behaviour of waitpid() is also how I noticed the
>>>> SIG_IGN.
>>>>
>>>
>>> Which does not change the situation with respect to handling SIGCLD,
>>> only
>>> for background threads calling waitpid() to collect exit statuses
>>> eagerly,
>>> in absence of exit notification.
>>>
>>> Your application can still re-trap SIGCLD to some handler, do the
>>> wait() to
>>> collect the exit status there, identifying your own threads based on the
>>> returned pid to take proper action. In that sense, the fact that the
>>> library
>>> initially ignores the signal does not change the general behavior if
>>> you do
>>> care for such signal afterwards.
>>>
>>> The issue in your case seems that you don't want to set any
>>> disposition for
>>> SIGCLD, and therefore expect that copperplate won't do it either. So the
>>> alternative for preventing zombies is between trusting the
>>> application for
>>> collecting all statuses properly, or asking the application to use the
>>> signal-based mechanism for collecting exit status. Option #2 is
>>> current, as
>>> you noticed it.
>>
>> I understand this reasoning and the fact that you can't trust the
>> application to handle all the zombies and thus your choice for option
>> #2. However I was just hoping there was an option #3 where the library
>> does leave the behaviour of the application as is and can handle the
>> daemon exit itself somehow.
>
> There is a simpler option: the library could install a valid handler
> instead of SIG_IGN, which the application could override. Whether the
> application does install its own handler or only copperplate does,
> zombies would be prevented. I'll push something along these lines.
>

To make this clearer: if copperplate traps SIGCHLD to a valid handler, 
with this handler calling waitpid(<regd-pid>, WNOHANG...), then you 
should still be able to wait() for child processes explicitly, without 
the copperplate handler reaping your child application processes 
inadvertently.

-- 
Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Kim De Mey]

2014-02-27 11:50 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
> On 02/27/2014 10:50 AM, Philippe Gerum wrote:
>>
>> On 02/27/2014 08:36 AM, Kim De Mey wrote:
>>>
>>> 2014-02-26 10:26 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>
>>>> On 02/25/2014 08:03 PM, Kim De Mey wrote:
>>>>>
>>>>>
>>>>> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>
>>>>>>
>>>>>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>>>>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>>>>>> spawn_daemon() call.
>>>>>>> I guess this choice was made to make sure no zombies of the daemon
>>>>>>> stay alive. Correct?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> This does however mean that the default behaviour of the application
>>>>>>> regarding the handling of children is changed. Now I wonder
>>>>>>> whether it
>>>>>>> is okay (as a rule/practice) for a library to change this
>>>>>>> behaviour of
>>>>>>> the application. Shouldn't we look for a solution where the behaviour
>>>>>>> of the application remains untouched?
>>>>>>>
>>>>>>
>>>>>> The default action for SIGCHLD is to ignore it. If the app wants to
>>>>>> handle
>>>>>> this signal specifically, it will have to trap it and figure out which
>>>>>> child
>>>>>> it cares about has exited in any case. So the library action for this
>>>>>> signal
>>>>>> does not change anything to the default case actually.
>>>>>>
>>>>>
>>>>> It is true that the default is to ignore it. However setting the
>>>>> action explicitly to ignore does change the termination behaviour of
>>>>> children. The children that terminate will no longer become zombies
>>>>> and behaviour of wait() and wait_pid() calls is thus different (see
>>>>> man page of waitpid()).
>>>>> This different behaviour of waitpid() is also how I noticed the
>>>>> SIG_IGN.
>>>>>
>>>>
>>>> Which does not change the situation with respect to handling SIGCLD,
>>>> only
>>>> for background threads calling waitpid() to collect exit statuses
>>>> eagerly,
>>>> in absence of exit notification.
>>>>
>>>> Your application can still re-trap SIGCLD to some handler, do the
>>>> wait() to
>>>> collect the exit status there, identifying your own threads based on the
>>>> returned pid to take proper action. In that sense, the fact that the
>>>> library
>>>> initially ignores the signal does not change the general behavior if
>>>> you do
>>>> care for such signal afterwards.
>>>>
>>>> The issue in your case seems that you don't want to set any
>>>> disposition for
>>>> SIGCLD, and therefore expect that copperplate won't do it either. So the
>>>> alternative for preventing zombies is between trusting the
>>>> application for
>>>> collecting all statuses properly, or asking the application to use the
>>>> signal-based mechanism for collecting exit status. Option #2 is
>>>> current, as
>>>> you noticed it.
>>>
>>>
>>> I understand this reasoning and the fact that you can't trust the
>>> application to handle all the zombies and thus your choice for option
>>> #2. However I was just hoping there was an option #3 where the library
>>> does leave the behaviour of the application as is and can handle the
>>> daemon exit itself somehow.
>>
>>
>> There is a simpler option: the library could install a valid handler
>> instead of SIG_IGN, which the application could override. Whether the
>> application does install its own handler or only copperplate does,
>> zombies would be prevented. I'll push something along these lines.
>>
>
> To make this clearer: if copperplate traps SIGCHLD to a valid handler, with
> this handler calling waitpid(<regd-pid>, WNOHANG...), then you should still
> be able to wait() for child processes explicitly, without the copperplate
> handler reaping your child application processes inadvertently.
>

That sounds good. Looks like it covers all the cases then. Thanks.

> --
> Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Philippe Gerum]

On 02/27/2014 12:54 PM, Kim De Mey wrote:
> 2014-02-27 11:50 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>> On 02/27/2014 10:50 AM, Philippe Gerum wrote:
>>>
>>> On 02/27/2014 08:36 AM, Kim De Mey wrote:
>>>>
>>>> 2014-02-26 10:26 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>
>>>>> On 02/25/2014 08:03 PM, Kim De Mey wrote:
>>>>>>
>>>>>>
>>>>>> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>
>>>>>>>
>>>>>>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>>>>>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>>>>>>> spawn_daemon() call.
>>>>>>>> I guess this choice was made to make sure no zombies of the daemon
>>>>>>>> stay alive. Correct?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> This does however mean that the default behaviour of the application
>>>>>>>> regarding the handling of children is changed. Now I wonder
>>>>>>>> whether it
>>>>>>>> is okay (as a rule/practice) for a library to change this
>>>>>>>> behaviour of
>>>>>>>> the application. Shouldn't we look for a solution where the behaviour
>>>>>>>> of the application remains untouched?
>>>>>>>>
>>>>>>>
>>>>>>> The default action for SIGCHLD is to ignore it. If the app wants to
>>>>>>> handle
>>>>>>> this signal specifically, it will have to trap it and figure out which
>>>>>>> child
>>>>>>> it cares about has exited in any case. So the library action for this
>>>>>>> signal
>>>>>>> does not change anything to the default case actually.
>>>>>>>
>>>>>>
>>>>>> It is true that the default is to ignore it. However setting the
>>>>>> action explicitly to ignore does change the termination behaviour of
>>>>>> children. The children that terminate will no longer become zombies
>>>>>> and behaviour of wait() and wait_pid() calls is thus different (see
>>>>>> man page of waitpid()).
>>>>>> This different behaviour of waitpid() is also how I noticed the
>>>>>> SIG_IGN.
>>>>>>
>>>>>
>>>>> Which does not change the situation with respect to handling SIGCLD,
>>>>> only
>>>>> for background threads calling waitpid() to collect exit statuses
>>>>> eagerly,
>>>>> in absence of exit notification.
>>>>>
>>>>> Your application can still re-trap SIGCLD to some handler, do the
>>>>> wait() to
>>>>> collect the exit status there, identifying your own threads based on the
>>>>> returned pid to take proper action. In that sense, the fact that the
>>>>> library
>>>>> initially ignores the signal does not change the general behavior if
>>>>> you do
>>>>> care for such signal afterwards.
>>>>>
>>>>> The issue in your case seems that you don't want to set any
>>>>> disposition for
>>>>> SIGCLD, and therefore expect that copperplate won't do it either. So the
>>>>> alternative for preventing zombies is between trusting the
>>>>> application for
>>>>> collecting all statuses properly, or asking the application to use the
>>>>> signal-based mechanism for collecting exit status. Option #2 is
>>>>> current, as
>>>>> you noticed it.
>>>>
>>>>
>>>> I understand this reasoning and the fact that you can't trust the
>>>> application to handle all the zombies and thus your choice for option
>>>> #2. However I was just hoping there was an option #3 where the library
>>>> does leave the behaviour of the application as is and can handle the
>>>> daemon exit itself somehow.
>>>
>>>
>>> There is a simpler option: the library could install a valid handler
>>> instead of SIG_IGN, which the application could override. Whether the
>>> application does install its own handler or only copperplate does,
>>> zombies would be prevented. I'll push something along these lines.
>>>
>>
>> To make this clearer: if copperplate traps SIGCHLD to a valid handler, with
>> this handler calling waitpid(<regd-pid>, WNOHANG...), then you should still
>> be able to wait() for child processes explicitly, without the copperplate
>> handler reaping your child application processes inadvertently.
>>
>
> That sounds good. Looks like it covers all the cases then. Thanks.
>

That one - from the next branch - should do, well, in theory (read: not 
even remotely tested).

http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=591427b13e1c655cb00157d6faa72e538cbd4f4b

Btw, you can also start sysregd manually, if the auto-exec is a burden. 
Copperplate will detect a running sysregd serving the proper fuse mount 
point, and refrain from forking off another daemon.

-- 
Philippe.

Re: [Xenomai] Xenomai-forge: SIGCHLD to SIG_IGN in spawn_daemon() okay?

[Kim De Mey]

2014-02-27 16:59 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
> On 02/27/2014 12:54 PM, Kim De Mey wrote:
>>
>> 2014-02-27 11:50 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>
>>> On 02/27/2014 10:50 AM, Philippe Gerum wrote:
>>>>
>>>>
>>>> On 02/27/2014 08:36 AM, Kim De Mey wrote:
>>>>>
>>>>>
>>>>> 2014-02-26 10:26 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>
>>>>>>
>>>>>> On 02/25/2014 08:03 PM, Kim De Mey wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2014-02-25 17:07 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/25/2014 10:07 AM, Kim De Mey wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> I noticed that when enabling the registry in Xenomai-forge (mercury
>>>>>>>>> core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
>>>>>>>>> spawn_daemon() call.
>>>>>>>>> I guess this choice was made to make sure no zombies of the daemon
>>>>>>>>> stay alive. Correct?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This does however mean that the default behaviour of the
>>>>>>>>> application
>>>>>>>>> regarding the handling of children is changed. Now I wonder
>>>>>>>>> whether it
>>>>>>>>> is okay (as a rule/practice) for a library to change this
>>>>>>>>> behaviour of
>>>>>>>>> the application. Shouldn't we look for a solution where the
>>>>>>>>> behaviour
>>>>>>>>> of the application remains untouched?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The default action for SIGCHLD is to ignore it. If the app wants to
>>>>>>>> handle
>>>>>>>> this signal specifically, it will have to trap it and figure out
>>>>>>>> which
>>>>>>>> child
>>>>>>>> it cares about has exited in any case. So the library action for
>>>>>>>> this
>>>>>>>> signal
>>>>>>>> does not change anything to the default case actually.
>>>>>>>>
>>>>>>>
>>>>>>> It is true that the default is to ignore it. However setting the
>>>>>>> action explicitly to ignore does change the termination behaviour of
>>>>>>> children. The children that terminate will no longer become zombies
>>>>>>> and behaviour of wait() and wait_pid() calls is thus different (see
>>>>>>> man page of waitpid()).
>>>>>>> This different behaviour of waitpid() is also how I noticed the
>>>>>>> SIG_IGN.
>>>>>>>
>>>>>>
>>>>>> Which does not change the situation with respect to handling SIGCLD,
>>>>>> only
>>>>>> for background threads calling waitpid() to collect exit statuses
>>>>>> eagerly,
>>>>>> in absence of exit notification.
>>>>>>
>>>>>> Your application can still re-trap SIGCLD to some handler, do the
>>>>>> wait() to
>>>>>> collect the exit status there, identifying your own threads based on
>>>>>> the
>>>>>> returned pid to take proper action. In that sense, the fact that the
>>>>>> library
>>>>>> initially ignores the signal does not change the general behavior if
>>>>>> you do
>>>>>> care for such signal afterwards.
>>>>>>
>>>>>> The issue in your case seems that you don't want to set any
>>>>>> disposition for
>>>>>> SIGCLD, and therefore expect that copperplate won't do it either. So
>>>>>> the
>>>>>> alternative for preventing zombies is between trusting the
>>>>>> application for
>>>>>> collecting all statuses properly, or asking the application to use the
>>>>>> signal-based mechanism for collecting exit status. Option #2 is
>>>>>> current, as
>>>>>> you noticed it.
>>>>>
>>>>>
>>>>>
>>>>> I understand this reasoning and the fact that you can't trust the
>>>>> application to handle all the zombies and thus your choice for option
>>>>> #2. However I was just hoping there was an option #3 where the library
>>>>> does leave the behaviour of the application as is and can handle the
>>>>> daemon exit itself somehow.
>>>>
>>>>
>>>>
>>>> There is a simpler option: the library could install a valid handler
>>>> instead of SIG_IGN, which the application could override. Whether the
>>>> application does install its own handler or only copperplate does,
>>>> zombies would be prevented. I'll push something along these lines.
>>>>
>>>
>>> To make this clearer: if copperplate traps SIGCHLD to a valid handler,
>>> with
>>> this handler calling waitpid(<regd-pid>, WNOHANG...), then you should
>>> still
>>> be able to wait() for child processes explicitly, without the copperplate
>>> handler reaping your child application processes inadvertently.
>>>
>>
>> That sounds good. Looks like it covers all the cases then. Thanks.
>>
>
> That one - from the next branch - should do, well, in theory (read: not even
> remotely tested).
>
> http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=591427b13e1c655cb00157d6faa72e538cbd4f4b

Tested this and it works.

>
> Btw, you can also start sysregd manually, if the auto-exec is a burden.
> Copperplate will detect a running sysregd serving the proper fuse mount
> point, and refrain from forking off another daemon.
>

I hadn't realized this yet, I tried it out now and that works also indeed.

Again many thanks for the help!

Regards,
Kim

> --
> Philippe.