Re: [RFC][PATCH] Notify init when processes are reparented to it

From: Oleg Nesterov
Date: Mon Dec 29 2008 - 11:00:00 EST


On 12/29, Scott James Remnant wrote:
>
> On Mon, 2008-12-29 at 14:23 +0100, Oleg Nesterov wrote:
>
> > > We want to be able to supervise daemons.
> >
> > What do you mean?
> >
> > > Later on, 1002 will die and init will receive SIGCHLD for it.
> > >
> > > Unfortunately neither the 1001 or 1002 processes are known to init, even
> > > though they are original children of the process it spawned (1000), for
> > > init to be notified about them - this has been forgotten.
> >
> > Ok, with this patch /sbin/init knows that 1002 is a descendant
> > of apache(1000) which was spwaned by init. What can init do
> > with this info?
> >
> Fundamentally init would now know that the apache service terminated,
> and with what exit code or by what signal.
>
> Right now, all we know is that a process terminated (and why) - we can't
> link that back to a service in any kind of foolproof manner.
>
> With the ability to do that, when the apache service dies, we can log
> that in a more useful manner (including marking the service as down) -
> but most importantly, we can respawn it!

Aha, thanks, I suspected something like this.

But how can we know (in general) that the service has died? We only
know that the process has exited.

IOW. when apache(1001) exits, we don't respawn. How can init know that
the death of apache(1002) means "this is the real exit of service, the
previous exits were due to initialization stage".

The only answer I can see is: because init can figure out that all
descendants of initially spawned apache(1000) have exited. But this
doesn't look very flexible/reliable to me.

And we already have CONFIG_PROC_EVENTS, init can monitor PROC_EVENT_FORK
events, so it can do this without ->adopt_signal ?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/