:: Re: [DNG] Openrc
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: Re: [DNG] Openrc
On Fri, 16 Sep 2016 15:51:43 +0200
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.


I can answer that. There are a lot of architectures in which the
supervisor isn't part of PID1, in which case the purist would say it
must be supervised at least enough, by PID1, that PID1 can respawn the
supervisor.

SteveT

Steve Litt
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28