On Sun, 14 Jun 2015 18:22:26 +0100 KatolaZ <kato...@freaknet.org> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng