From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1294 Path: news.gmane.org!not-for-mail From: Charlie Brady 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: Mon, 30 Oct 2006 09:51:43 -0500 (EST) Message-ID: References: <4543AEE3.50200@alex-smith.me.uk> <20061030104923.GC32166@home.power> <20061030121321.GA27602@fly.srk.fer.hr> <20061030123019.GA30814@home.power> <20061030133847.GA25085@skarnet.org> <20061030134227.GA23323@home.power> <20061030135834.GA26907@skarnet.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: sea.gmane.org 1162220160 28031 80.91.229.2 (30 Oct 2006 14:56:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2006 14:56:00 +0000 (UTC) Cc: supervision@list.skarnet.org Original-X-From: supervision-return-1530-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Oct 30 15:55:55 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 1GeYUX-0005vb-QE for gcsg-supervision@gmane.org; Mon, 30 Oct 2006 15:51:57 +0100 Original-Received: (qmail 30798 invoked by uid 76); 30 Oct 2006 14:52:19 -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 30788 invoked from network); 30 Oct 2006 14:52:18 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: charlieb.ott.istop.com X-X-Sender: charlieb@e-smith.charlieb.ott.istop.com Original-To: Laurent Bercot In-Reply-To: <20061030135834.GA26907@skarnet.org> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1294 Archived-At: On Mon, 30 Oct 2006, Laurent Bercot wrote: > Another approach to the throttle feature that doesn't require notification > from runit would be to have a short-lived program, designed to be called in > the finish script, that stores its information (last calling time ans such) > in the filesystem. Maybe it's what you were thinking about. But I'm not > sure how to make it reliable; storing short-lived information in the > filesystem is very error-prone, that's the .pid way, which is precisely > what supervision tools were designed to avoid. The problem with pid files is race conditions. I don't see that as being a problem here, as there is a single thread of execution between ./run and ./finish. ./finish should be able to reliably store whatever state it needs in the file system. Or do you see something which I don't?