From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1302 Path: news.gmane.org!not-for-mail From: Alex Efros Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Option for runsv/runsvdir to specify how many times to restart a service in a certain time period before giving up? Date: Tue, 31 Oct 2006 00:03:48 +0200 Organization: asdfGroup Inc., http://powerman.asdfGroup.com/ Message-ID: <20061030220348.GC12402@home.power> References: <4543AEE3.50200@alex-smith.me.uk> <20061030104923.GC32166@home.power> <20061030121321.GA27602@fly.srk.fer.hr> <20061030123019.GA30814@home.power> <20061030184923.GA20787@fly.srk.fer.hr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1162245863 30358 80.91.229.2 (30 Oct 2006 22:04:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2006 22:04:23 +0000 (UTC) Original-X-From: supervision-return-1538-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Oct 30 23:04:20 2006 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by ciao.gmane.org with smtp (Exim 4.43) id 1GefET-0003oj-Q7 for gcsg-supervision@gmane.org; Mon, 30 Oct 2006 23:03:49 +0100 Original-Received: (qmail 18883 invoked by uid 76); 30 Oct 2006 22:04:11 -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 18877 invoked from network); 30 Oct 2006 22:04:11 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20061030184923.GA20787@fly.srk.fer.hr> User-Agent: Mutt/1.5.13 (2006-08-11) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1302 Archived-At: Hi! On Mon, Oct 30, 2006 at 07:49:23PM +0100, Dra?en Ka?ar wrote: > It does. Ease of configuration, for example. If an administrator has to > configure programs with shell scripts, another admin has to find, read and > understand those scripts before he can change anything. That's an overhead > I'd like to avoid for simple things. I tend to agree. But I've two comments: 1) In my experience most *nix admins know only about sysvinit, and when they see server with runit/daemontools they just give up. So, small feature in ./finish script doesn't make task much harder for such admins. Other admins, who know about runit, know ./finish scripts isn't usually used at all, so if they see ./finish script they usually look into it with curiosity. :) 2) Windows is example of thing developed to be ease to configure. I prefer harder to configure but more controlled things like *nix. > Suppose the problem was fixed, but runit is waiting for the finish scripts > to exit. How does one tell them to exit immediately and let runsv restart > the services? This is same interesting question as Alex Smith asked. I don't know, we should ask Gerrit. Maybe signals will work... > > After all, it's a Unix Way. > It's a way of the people who like to write shell scripts. I don't like to write shell scripts. Unix Way is to have a lot of simple programs each doing it small task. I.e. if some task can be split into two different programs - why not go this way? Each program will be more simple and so more reliable and have less bugs. But evil side of this is effort to integrate all these programs (using shell scripts or something else), yeah. Actually, there few exceptions from this rule in *nix world - text editor Vim, for example, or email client Mutt - they both are big complex programs, and that's good because these programs should parse user input and provide comfortable user interface - that's impossible for bundle of small programs. But I don't think runit is fall into this software category - it should be reliable, secure, fast, simple and small. This goal much ease to reach using Unix Way of programming. And so, yes, you should use shell scripts to help runit stay small and reliable. -- WBR, Alex.