On Sun, 14 Jun 2015 18:22:26 +0100
KatolaZ <katolaz@???> wrote:

> On Sun, Jun 14, 2015 at 10:35:48AM -0400, Stephanie Daugherty wrote:
>
> [cut]
>
> >
> > A professional service of any sort should have monitoring - the
> > administrator should be alerted within minutes if a service doesn't
> > start when it should or goes down when it shouldn't,
> >
> > Getting a little off topic at this point, but opinions vary as to
> > whether the monitoring should actually restart the service or not.
> > I'm firmly in the camp that process supervision is evil, because
> > service failures on a *nix system should not happen, and when they
> > do they should be a really big inconvenient deal that wakes people
> > up at 3am - because that's the sort of thing that gets problems
> > noticed and fixed. Process supervision trivializes failures, and
> > leads us down a path of *tolerating* them and fixing the symptoms
> > instead of fixing the problem - a really dangerous path when
> > exploitable code and malicious input are very common causes of
> > service failure.
>
> That's exactly the point. I believe the problem is delegating to init
> too many things, including process monitoring, restart, singnalling,
> etc. Maybe I am just a caveman, but I am firmly convinced that there
> is no way to make system administration simple or automatic.
>
> HND
>
> KatolaZ

Timing is everything, KatolaZ :-)

I just got done with an init setup with a complete separation of PID1
(Suckless Init: does nothing but fork /bin/rc.init and then sit around
handling signals), and a process manager (daemontools-encore). Two
completely separate things. The process manager gets delegated process
monitoring, restart, singnalling, and etc. That's what it's made to do.
But Suckless Init does one thing and does it well: listens for and
handles signals. Nothing else delegated to it.

Others can correct me, but I'm pretty sure with runit, the runit-init
executable itself is PID1, with the runit executable handling process
supervision pretty much the same way daemontools-encore does. So runit,
not runit-init, gets all the "stuff" delegated to it.

From years of sysvinit, and months of systemd, we've become accustomed
to PID1 duties and process management duties being tightly coupled, but
it doesn't have to be that way at all.

I think Rich Felker explains it best:

http://ewontfix.com/14/

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key