From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/737 Path: news.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Adding a 'setup' phase to service startup? Date: Mon, 7 Mar 2005 11:56:12 +0000 Message-ID: <20050307115343.3584.qmail@786f5a78e3b7ba.315fe32.mid.smarden.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110196078 16840 80.91.229.2 (7 Mar 2005 11:47:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2005 11:47:58 +0000 (UTC) Original-X-From: supervision-return-976-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Mar 07 12:47:58 2005 Original-Received: from antah.skarnet.org ([212.85.147.14] ident=qmailr) by ciao.gmane.org with smtp (Exim 4.43) id 1D8GiF-0001uW-VZ for gcsg-supervision@gmane.org; Mon, 07 Mar 2005 12:47:52 +0100 Original-Received: (qmail 22968 invoked by uid 76); 7 Mar 2005 11:53:44 -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 22963 invoked from network); 7 Mar 2005 11:53:44 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: X-MailScanner-To: gcsg-supervision@gmane.org Xref: news.gmane.org gmane.comp.sysutils.supervision.general:737 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:737 On Mon, Feb 21, 2005 at 05:41:59PM +0000, Lars Kellogg-Stedman wrote: > I was mulling over service dependencies yesterday, and I wonder if it would > make sense to add a "setup" phase to runsv's service startup sequence. > This would allow, for example, svwaitup to block while a service performed > one time initialization. > > Here I'm thinking particularly of long-running setup actions, such as > database initialization or something. The current solution -- waiting for > a number of seconds and then crossing our fingers -- doesn't provide the > level of control that runit provides in other areas. Yes, true. I don't consider svwaitup as the current solution, but as a workaround. The fix actually should be in the service daemons I think, see http://smarden.org/runit/dependencies.html > This would make the start sequence look like this: [...] > svwaitup() would block if a service was in the "setup" phase. This should > require only minor changes to runit -- introduce "runsv" to the "setup" > script, and modify svwaitup, svwaitdown, and runsvstat to understand a new > state value in the status file. This doesn't eliminate the race condition, just lets it look a bit better. I'm still looking for examples why service dependencies, more than runit currently provides, is needed. What are these services that must be started not before another service has been started and is available, and that don't recognize the error if the service depended upon isn't available? How do these services behave on that error condition?, shouldn't they log the error and fail? What are these services that need to be taken down manually after a service they depend upon became down? How do they behave if a service they need has been available on startup, but disappears while uptime?, shouldn't they log the error and fail, or maybe retry? What other problems are service dependencies meant to solve? I'm aware of one example, the problem that service daemons that log through syslog cannot know whether the syslog service is enabled, simply because the corresponding unix functions return void. To work around this for services that cannot switch to the runit logging facility, I added the socklog-check program to the socklog package. This program checks for a listener on (e.g.) /dev/log, and fails if the socket isn't maintained; it can be added to the top of the run script with set -e or as `socklog-check unix /dev/log || exit 1` to prevent the service from being started in this case. Thanks, Gerrit.