From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2088 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: [announce] perp-2.03: persistent process supervision Date: Mon, 14 Mar 2011 19:34:37 +0100 Message-ID: <20110314183437.GA18712@skarnet.org> References: <20110314113933.3544df05@b0llix.net> <20110314131706.GA17316@skarnet.org> <20110314150225.7cf61c3c@b0llix.net> <4D7E24DA.2030404@robinbowes.com> <20110314153425.34ed16dc@b0llix.net> <20110314164741.GA7248@skarnet.org> <20110314183924.4dc40065@b0llix.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1300127536 1163 80.91.229.12 (14 Mar 2011 18:32:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2011 18:32:16 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-2322-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Mar 14 19:32:11 2011 Return-path: Envelope-to: gcsg-supervision@lo.gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1PzCYs-0003qr-W4 for gcsg-supervision@lo.gmane.org; Mon, 14 Mar 2011 19:32:11 +0100 Original-Received: (qmail 23012 invoked by uid 76); 14 Mar 2011 18:34:37 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 23004 invoked by uid 1000); 14 Mar 2011 18:34:37 -0000 Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20110314183924.4dc40065@b0llix.net> User-Agent: Mutt/1.4i Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2088 Archived-At: > It is like worrying, what if init(8) should die? No, not exactly, because init(8) is process 1. If perpd is meant to be run as process 1, then I have no more questions - it just will not die, as you say. But if it is not, it is legitimate to wonder about it dying. And btw, I do worry about process 1 dying, not from murder, which is not possible, but from simple illness, i.e. bugs. That is why I do not trust Upstart, or MacOS X launchd, or even sysvinit's init: those programs are too complex for anyone to be able to guarantee that they can't die, and they don't leak memory, and they don't have any other bug of the kind. Process 1, the ultimate long-lived process on a system, should be *proven* to work, and complexity is antagonistic to that. > If a system is delivering random SIGKILL, one should select > another system. There is no peaceful, confident sleeping at > night otherwise, no matter what supervisory framework you choose. But the point of supervision is to make up for deficiencies in the real world ! I don't need the daemons I write to be supervised, because I know how to write daemons, and they just Do Not Die (TM). Who needs automatic respawning when there is no bug in your programs and they just work ? In a perfect world, none of the work we're doing here would be necessary ! Unfortunately, we're not living in a perfect world, and stuff happens. We're just building additional safeguards to ensure that even when the improbable happens, our systems keep working. If a SIGKILL hitting perpd is just too improbable for you and you do not want to cover that case ("perp offers no guarantee against acts of God, malevolent or stupid root account holders, or buggy Linux OOMs"), that's perfectly fine, and perp will still be basically usable about 100% of the time. But, well, I like to turn the paranoia to the max and be able to say "it still works". :) > If we talk in terms of daemontools, svscan(8) already keeps a > table of supervise(8) processes, and svscan itself functions as a > supervisor of those multiple supervise(8)s. So it is not much of > a conceptual jump, nor extra info, to simply eliminate the > supervise(8) "middlemen", and have svscan supervise the services > directly. Oh, I am not attacking perp's design at all. I welcome alternatives in the world of supervision suites. My own take on the matter, s6 (to be released as soon as the doc is written, which means... someday), is a daemontools-like design, and we were lacking an init-like design. Variety is good, and I don't think perpd's design is a fundamental flaw - I have reasons for liking daemontools' design better, but they're mostly maintainability- and aesthetics-related. If every Unix admin in the world used perp, or runit, I would be a happy man. Anything we have here is so much better than what mainstream offers. > perpd does provide redundant supervision with perpboot/inittab > by default when installed with perp-setup(8). Imagining any > extra security from additional layers of supervision is merely a > placebo It's not about adding layers, it's about dividing responsibilities. I'll elaborate on this later, right now I have a bus to catch. -- Laurent