From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/726 Path: main.gmane.org!not-for-mail From: Thomas Schwinge Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Adding a 'setup' phase to service startup? Date: Tue, 22 Feb 2005 16:06:01 +0100 Message-ID: <20050222150601.GA28347@googlitzsch.de> References: <421AB049.4040403@gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109084623 24664 80.91.229.2 (22 Feb 2005 15:03:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Feb 2005 15:03:43 +0000 (UTC) Cc: supervision@list.skarnet.org Original-X-From: supervision-return-965-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Feb 22 16:03:43 2005 Original-Received: from antah.skarnet.org ([212.85.147.14] ident=qmailr) by ciao.gmane.org with smtp (Exim 4.43) id 1D3bYW-0007mj-59 for gcsg-supervision@gmane.org; Tue, 22 Feb 2005 16:02:32 +0100 Original-Received: (qmail 18789 invoked by uid 76); 22 Feb 2005 15:06:28 -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 18783 invoked from network); 22 Feb 2005 15:06:28 -0000 Original-To: Dean Hall Mail-Followup-To: Dean Hall , supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <421AB049.4040403@gmail.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-Provags-ID: kundenserver.de abuse@kundenserver.de login:c9c8b863173b56dc4a0242d71aa058ab X-MailScanner-To: gcsg-supervision@gmane.org Xref: main.gmane.org gmane.comp.sysutils.supervision.general:726 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:726 On Mon, Feb 21, 2005 at 11:08:41PM -0500, Dean Hall wrote: > 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.) Just an idea: What about using an executable '/service/S/status' that can be used by a service R to check if the service S is working? This executable's interface would have to be standardized, of course. If '/service/S/status' is not executable, a default of 'svwaitup /service/S' could be used. Example /service/sshd/status #v+ #!/bin/sh # exit 100 if the service can't be running. if svok . || runsvstat . then : else exit 100 fi && # exit 111 if the service might be running, but doesn't accept connections. tcpclient -H -l 0 -R 127.0.0.1 22 true # exit 0 if the service is accepting connections. #v- A service Q, depending on sshd (whatever that might be), could run 'cd /service/S && ./status' and use it's exit code to get aware of S's status. Of course, if that check is done from '/service/Q/run', Q will show up as "running" at the time it is only checking if its dependencies are met. So, every service depending on Q's operativeness would have to check '/service/Q/status' in turn... Perhaps runsv could run e.g. '/service/Q/check' before execing into '/service/Q/run'? '/service/Q/check' could also make sure that Q is not restarted too frequently (Thread "Respawn limit for runsv?"). > 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'd say it's on topic here. #v+ * supervision: Discussion about system services, daemon supervision, init, runlevel management, and tools such as daemontools' svscan and supervise, or runit. #v- Regards, Thomas