From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1983 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Configuration services Date: Tue, 28 Jul 2009 07:52:51 +0200 Message-ID: <20090728055251.GA29760@skarnet.org> References: <20090726162204.GA19230@pretender.frop.net> <20090727085635.GO30106@fencepost.gnu.org> <20090728020821.GA25002@pretender.frop.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248760304 26640 80.91.229.12 (28 Jul 2009 05:51:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jul 2009 05:51:44 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-2218-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Jul 28 07:51:37 2009 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1MVfb6-0007gF-C6 for gcsg-supervision@gmane.org; Tue, 28 Jul 2009 07:51:36 +0200 Original-Received: (qmail 4971 invoked by uid 76); 28 Jul 2009 05:52:52 -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 4959 invoked by uid 1000); 28 Jul 2009 05:52:52 -0000 Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20090728020821.GA25002@pretender.frop.net> User-Agent: Mutt/1.4i Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1983 Archived-At: > I want to be able to have other services depend on it. > (cut) > I also have a ./finish script that undoes all the configuration ... and if a stray signal happens to kill your shell, your "service" will be deconfigured and reconfigured. The supervisor is there to ensure a process remains up no matter what; it's suppoed to maintain a *process*, not a *state*. The only state it can guarantee is 'want up', i.e. if the process ever goes down, you can be sure it will be run again. You are not the first to want to use the daemontools/runit pattern as a dependency manager, implementing a wider notion of 'service' than it really does. As far as I can tell, this is not a very good idea - it can be made to work, but it's generally shaky and unsatisfying. As a rule of thumb, whenever you have a loop in your run script, you are probably abusing the pattern. The supervision tree that svscan/supervise or runsvdir/runsv gives you is a *process* tree; and the whole system is about supervising *processes*. DJB started naming 'services' the supervised processes because most services can be implemented via a run script setting up some environment and executing into a daemon; but it's obvious that people have a wider definition of 'service'. For instance, keeping a net interface up should legitimately be called a service, but most Unix implementations do not need a process that runs constantly to achieve that; and *adding* a process to be controlled by a supervisor to emulate a down/up service state is resource-consuming (even if it's as light as a "sleep" binary) and should not be needed. It's trying to fit a square peg into a round hole. Don't misunderstand me, I'm a fervent advocate of daemontools/runit, and I believe it's a wonderful pattern, a necessary basis of any reliable Unix implementation, and a very sound *fundation* for a dependency management system. But per se, it's not a dependency management system: it's a process management system. What we need is another piece of software, using the supervision tree as an underlying layer, that does proper dependency management and handles a wider notion of 'service' than daemontools/runit. As far as I know, such a piece of software still remains to be written. In the meantime, you can certainly use daemontools/runit as a service dependency manager, but there *will* be holes and awkwardnesses in your system, and you're going to have to consume extra resources to make it work. -- Laurent