> On September 16, 2016 at 9:51 AM Didier Kryn <kryn@???> wrote:
>
> Le 16/09/2016 13:15, KatolaZ a écrit :
> > On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> >
> > [cut]
> >
> >> Steve,
> >>
> >> I like more and more this idea of separating the tasks:
> >> - pid1 (sysvinit or whatever) performs one-shot startups and basic
> >> supervision (like for getty),
> >> - services needing a sophisticated supervisor use a supervisor which is
> >> only a supervisor, not pid1,
> >> - services which depend on conditions use specialized tools to wait for
> >> these conditions.
> >>
> > That looks like a great plan, but who will supervise the supervisors?
> > :)
> >
> > I admit this might seem like a stupid comment, at least at first
> > sight, but whenever you introduce a supervision system under unix you
> > most probably end up deciding that the supervision should be delegated
> > to pid1, since pid1 is the only process able to guarantee that
> > supervision will be working, whatever happens.
> Nobody supervises pid1, OK? So why would the supervisor need to be
> supervised? It is supposed to be rock solid. Note that it can be barely
> relaunched by sysvinit in the same way as getty.
>
> Didier
In the spirit of the minimal PID1 in 30 lines of code, I would propose that one of the RC tasks spawned by it would be the minimal supervisor in about 30 lines of code, which only supervises supervisors and knows how to launch/relaunch them. Failure unlikely. The OOM killer won't ever see it, right?
It would require a separation in PID1's RC to move supervisable things into the other list, or perhaps a way for a PID1 supervisable task to ask for other supervision. Bleah, this could be more clearly expressed :-)
Peter Olson
::
Re: [DNG] Openrc
