I investigated this further and saw that it us not the case when using the ‘respawn’ keyword as one can easily see here from init.c:
/* Run all commands of a particular type */
static void run_actions(int action_type)
{
struct init_action *a;
for (a = init_action_list; a; a = a->next) {
if (!(a->action_type & action_type))
continue;
if (a->action_type & (SYSINIT | WAIT | ONCE | CTRLALTDEL |
SHUTDOWN)) {
pid_t pid = run(a);
if (a->action_type & (SYSINIT | WAIT | CTRLALTDEL |
SHUTDOWN))
waitfor(pid);
}
if (a->action_type & (RESPAWN | ASKFIRST)) {
/* Only run stuff with pid == 0. If pid != 0,
* it is already running
*/
if (a->pid == 0)
a->pid = run(a);
}
}
}
Is it a bug or a feature??? If it is a feature then runsvdir needs to have a
signal handler for reaping its children.
//Markus
On 23 Dec 2017, at 09:13 , Laurent Bercot <ska-dietl...@skarnet.org> wrote:
>> What is the rationale behind not reaping the children when the program
>> exists? i run it from inittab as a respawn process and I get zombies when
>> killing it when not reaping children alas the fix was pretty simple.
>
> Unless you're running runsvdir as process 1, there's no reason to do
> so, because on runsvdir's death, its children will be reassigned to
> init, and init will reap those zombies.
>
> If you're getting zombies when killing runsvdir, then you have
> another problem, that is unrelated to runsvdir.
>
> Note that busybox init sometimes takes one second to reap zombies
> (which is what you may have observed). This is a flaw in the design
> and cannot be fixed without significantly rewriting it, but it
> should not matter for practical purposes - zombies hanging around for
> one second is generally not an issue.
>
> --
> Laurent
>
> _______________________________________________
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
//Markus - The panama-hat hacker
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
