From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/839 Path: news.gmane.org!not-for-mail From: Mike Bell Newsgroups: gmane.comp.sysutils.supervision.general Subject: Dependencies for runit (again) Date: Tue, 9 Aug 2005 10:03:50 -0700 Message-ID: <20050809170349.GF20253@mikebell.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1123607085 32461 80.91.229.2 (9 Aug 2005 17:04:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2005 17:04:45 +0000 (UTC) Original-X-From: supervision-return-1075-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Aug 09 19:04:44 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by ciao.gmane.org with smtp (Exim 4.43) id 1E2XVd-0000sp-Qq for gcsg-supervision@gmane.org; Tue, 09 Aug 2005 19:03:25 +0200 Original-Received: (qmail 13259 invoked by uid 76); 9 Aug 2005 17:03:46 -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 13254 invoked from network); 9 Aug 2005 17:03:46 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline User-Agent: Mutt/1.5.9i Xref: news.gmane.org gmane.comp.sysutils.supervision.general:839 >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 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). 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. 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. - probably other things I haven't thought of. Comments?