From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/840 Path: news.gmane.org!not-for-mail From: Stefan Karrmann Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Dependencies for runit (again) Date: Tue, 9 Aug 2005 22:34:50 +0200 Message-ID: <20050809203450.GA9095@johann.karrmann.de> References: <20050809170349.GF20253@mikebell.org> Reply-To: sk@mathematik.uni-ulm.de NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1123619863 32502 80.91.229.2 (9 Aug 2005 20:37:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2005 20:37:43 +0000 (UTC) Original-X-From: supervision-return-1076-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Aug 09 22:37:42 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by ciao.gmane.org with smtp (Exim 4.43) id 1E2apW-0004JD-VP for gcsg-supervision@gmane.org; Tue, 09 Aug 2005 22:36:11 +0200 Original-Received: (qmail 14420 invoked by uid 76); 9 Aug 2005 20:36:32 -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 14415 invoked from network); 9 Aug 2005 20:36:32 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20050809170349.GF20253@mikebell.org> Mail-Reply-To: X-MailKey: xkJ5TvOgzl4Iya5d0JvKP8S_ztRnvAgZAz X-Passkey: b8b2906d4f8f939edc6277942ddcc3f2b97cab9774309f1ccbef5b9255c9e703 User-Agent: Mutt/1.5.9i Original-Sender: S.Karrmann@web.de X-Sender: S.Karrmann@web.de Xref: news.gmane.org gmane.comp.sysutils.supervision.general:840 Dear all, Mike Bell (Tue, Aug 09, 2005 at 10:03:50AM -0700): > From discussions on some list set up to discuss an alternative init > system for debian, I've garnered three main issues with runit's > current dependency system: > > - It's not programmatically parsable, only a human can tell that a rule > at the top of a shell script checking for a given socket is actually > waiting for postgres. Prevents > - It encourages code duplication. The code to check if service X is up > is not in service X's directory, but rather scattered over the run > scripts of the services which depend upon it. [1] > - The "repeatedly exec until service is up" method seems to bother > people. IMHO, the latter is a main point of daemontools and runit. > I believe there may be advantages to considering a "proper" dependency > system for runit. > > What I had in mind was firstly the addition of a new shell script in the > service's directory (anyone got a good name?), designed to test whether my 2 ¢: `accepting' - think of sockets. You may use pipe-tools if you prefer events over polling. > the service is currently running. In its absence we would have to rely > on the "it hasn't restarted for a while" method. > > Secondly, a new directory in a service directory, named dependencies, > which contains symlinks to other service directories. runsv then ensures > that each of these services is running (by either using the > aforementioned "am I up" test script itself, or by having the runsv of > the service itself use said script and then report the status). Why should runsv do the work? Write a new command, e.g. `start-dependencies', which starts all services in the sub-directory dependencies. Then run it as first command from the run-command of a service. How are the signals from runit or supervise handled here? > Thirdly, though I'm not certain of the need for this, another directory > like the above describing services which should be taken down along with > the current service. Again, why should runsv do it? Write `stop-dependencies' and enter it into the finish-command of the service. > It's a fairly simple set of changes, but... > - it gets you dependencies which can be machine parsed and managed > easily. > > - it moves the detection of a daemon's status into that daemon itself > where it belongs - rather than having it duplicated in each of the > dependencies. > > - it allows you to do virtual dependencies (contrived example, daemon X > depends on either mysql or postgresql. Its dependencies simply link to > sql-server rather than either one specifically. Certainly a lot easier > than a mess of shell scripting with logical ors to detect each sql > daemon it can use.) > > - it fits better with package management. An upgrade to postgresql may > change the method for detecting if it's up, but with current runit > you'd have to also update every package which depends on postgresql. > > - it reduces the spin-and-die people seem to dislike so much about > runit. Particularly for a very complicated setup with a lot of daemons > depending on a single one (directly or indirectly) this could be a > significant reduction. Regards, -- Stefan