From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/725 Path: main.gmane.org!not-for-mail From: Dean Hall Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Adding a 'setup' phase to service startup? Date: Mon, 21 Feb 2005 23:08:41 -0500 Message-ID: <421AB049.4040403@gmail.com> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1109045056 19465 80.91.229.2 (22 Feb 2005 04:04:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Feb 2005 04:04:16 +0000 (UTC) Original-X-From: supervision-return-964-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Feb 22 05:04:16 2005 Original-Received: from antah.skarnet.org ([212.85.147.14] ident=qmailr) by ciao.gmane.org with smtp (Exim 4.43) id 1D3RHO-0002TD-R3 for gcsg-supervision@gmane.org; Tue, 22 Feb 2005 05:04:11 +0100 Original-Received: (qmail 13881 invoked by uid 76); 22 Feb 2005 04:08:01 -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 13875 invoked from network); 22 Feb 2005 04:08:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:x-enigmail-version:x-enigmail-supports:content-type:content-transfer-encoding; b=PdDZUgaa9ywFdGauDGOXg60fgqiySp7QUYBACGJhnNt+RwuqfNroHLX5dIaxm8DtxPbqdomtIvuzQEY/ARLrw2+0Bi1IvT9efxTQLdlkUq3HdAO8ru8R3M5yBqiSqXlv8/OqGIVpMmC1o4cNXZSV7UUDXVYWKD7rFvX879F+yJE= User-Agent: Mozilla Thunderbird 1.0 (X11/20050124) X-Accept-Language: en-us, en Original-To: supervision@list.skarnet.org In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-MailScanner-To: gcsg-supervision@gmane.org Xref: main.gmane.org gmane.comp.sysutils.supervision.general:725 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:725 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Although I think runit itself should remain pristine in that it only runs the ./run script for a service, I'm working on a system initialization scheme that factors something just like this in. See my initial draft of the scheme at ; please note that it has changed significantly since the first reference release. In particular, what the relevant part of sysinit does is create an infrastructure for resolving both runit-managed and arbitrary dependencies that does not depend on svwaitup (whose ability to resolve dependencies is fundamentally flawed). Basically, in its current incarnation, sysinit takes the following steps in ./run: 1) It optionally checks a configurable directory for a series of dependencies. A dependency, in this case, is a file in that directory. If the file is a directory (or symlink to one), it is expected to be a runit-managed service; if it is running (using a method described below), the dependency is considered resolved. If the file is an executable file (or a symlink to one), it is run; if it returns 0, the dependency is considered resolved. (That is the part that I think could solve your initialization question.) If any dependency fails, the service initialization is abandoned and can optionally stop the service or simply exit (and allow runit to try again) after an optional delay. 2) If all dependencies resolve, sysinit creates a lockfile for the service (separate from runit's) and starts it. (This is how service dependencies are resolved. Thus, a service is not considered started until all its dependencies are resolved and the service proper is actually running. This does not solve more fundamental race conditions--such as when a service starts but immediately fails, and another service checks its dependency in the short time in which the service is running--but I don't think those are solvable in any straightforward fashion, and I'm not sure if they should, as such race conditions indicate very severe problems that usually require human intervention.) If anyone wants to talk to me about this privately, feel free to email me here. Or we can talk about it on the list if it's okay with Gerrit. I'm open to suggestions about how I can improve my system, and I'd be glad to email out the new implementation (in progress) for inspection and suggestions. Dean > 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. > > This would make the start sequence look like this: > > IF file "setup" exists THEN > SET STATE TO S_SETUP > RUN file "setup" > END IF > > SET STATE TO S_RUN > RUN file "run" > > IF file "finish" exists THEN > SET STATE TO S_FINISH > RUN file "finish" > END IF > > 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. > > -- Lars > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCGrBIY5YOge8zySQRAl4YAKCAm5FlsWNOhFZL8EerqkytmOU7fACdHZ+9 To6fK4MQbN/QQzWTvGRNmhc= =sBSs -----END PGP SIGNATURE-----