From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/845 Path: news.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Dependencies for runit (again) Date: Fri, 12 Aug 2005 17:25:41 +0000 Message-ID: <20050812172432.6467.qmail@ba17571ef25f7d.315fe32.mid.smarden.org> References: <20050809170349.GF20253@mikebell.org> <20050809203450.GA9095@johann.karrmann.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1123867561 27066 80.91.229.2 (12 Aug 2005 17:26:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Aug 2005 17:26:01 +0000 (UTC) Original-X-From: supervision-return-1081-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Aug 12 19:25:57 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by ciao.gmane.org with smtp (Exim 4.43) id 1E3dHg-0005vE-WD for gcsg-supervision@gmane.org; Fri, 12 Aug 2005 19:25:33 +0200 Original-Received: (qmail 9620 invoked by uid 76); 12 Aug 2005 17:25:54 -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 9615 invoked from network); 12 Aug 2005 17:25:54 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20050809203450.GA9095@johann.karrmann.de> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:845 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:845 On Tue, Aug 09, 2005 at 10:34:50PM +0200, Stefan Karrmann wrote: > 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. > > 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. We have ./run and ./finish, I would call it ./check. > > 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. Yes, I think Mike's ideas are pretty thought through, and can well be tested with runit, only implemented through the scripts, see also http://article.gmane.org/gmane.linux.debian.devel.initscripts-ng/27 How about a subdirectory ./depends/ in the service directory containing links or files naming the dependencies, and this in the ./run script?: #!/bin/sh for i in `ls -1 ./depends/ 2>/dev/null || :`; do sv start $i || exit 1 ! test -x /var/service/$i/check || $_ || exit 1 done exec service-daemon > > 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. Or in the ./control/d script. Restarting dependent services if a service restarts normally shouldn't be necessary, but people might want to take dependent services down automatically when taking a specific service down, I'm not sure. > > It's a fairly simple set of changes, but... > > - it gets you dependencies which can be machine parsed and managed > > easily. # ls -1 /var/service/foo/depends/ # ls /var/service/*/depends/foo > > - 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. Yes, sounds good. Regards, Gerrit.