From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1345 Path: news.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: graceful restart under runit Date: Wed, 22 Nov 2006 14:51:13 -0500 Organization: What did you have in mind? A short, blunt, human pyramid? Message-ID: References: <20061117001519.GA652@home.power> <20061117133435.GB2153@home.power> <20061118002245.GB17975@home.power> <20061118123120.GA8388@home.power> <20061120182733.GA629@fly.srk.fer.hr> <20061122192506.GA24958@fly.srk.fer.hr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1164225086 19867 80.91.229.2 (22 Nov 2006 19:51:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 22 Nov 2006 19:51:26 +0000 (UTC) Cc: supervision@list.skarnet.org Original-X-From: supervision-return-1581-gcsg-supervision=m.gmane.org@list.skarnet.org Wed Nov 22 20:51:23 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 1Gmy7s-0003PN-2p for gcsg-supervision@gmane.org; Wed, 22 Nov 2006 20:51:21 +0100 Original-Received: (qmail 13918 invoked by uid 76); 22 Nov 2006 19:51:41 -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 13913 invoked from network); 22 Nov 2006 19:51:41 -0000 Original-To: =?iso-8859-2?Q?Dra=BEen_Ka=E8ar?= In-Reply-To: <20061122192506.GA24958@fly.srk.fer.hr> (=?iso-8859-2?Q?Dra?= =?iso-8859-2?Q?=BEen_Ka=E8ar's?= message of "Wed, 22 Nov 2006 20:25:06 +0100") Mail-Copies-To: nobody Mail-Followup-To: =?iso-8859-2?Q?Dra=BEen_Ka=E8ar?= , supervision@list.skarnet.org Original-Lines: 62 User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1345 Archived-At: Dra=BEen Ka=E8ar wrote: > Paul Jarc wrote: >> Also, using a socket means you have two-way communication, so you >> don't need signals or PID files, which are subject to race conditions. > > Files maybe are, but signals? Unless you're sending signals to your own child process, there's a chance that the process you're signaling has already died, and its PID has been reused for a new process. This is true no matter how you obtain the PID to send signals to; PID files are just one case of that. The only exception is for the parent, which knows that the child's PID hasn't been recycled because, even if the child has exited, the parent hasn't wait()ed for the child yet. > A server binds to the file system socket after it got the network socket, > either by a direct bind() or by a passover from an existing server. That > should be enough, I think. It's not atomic, but it's a locking protocol. Actually, obtaining the network socket can be atomic enough - bind() is atomic, and each server process can limit itself to passing the network socket to at most one other server, so there's no chance of one server getting a network socket while another is in the middle of receiving it in a handoff. That's all the atomicity we need. It can get messy if two servers start at the same time - A will get the network socket, so B will try to connect to the filesystem socket, but A might not be listening there yet. B could handle this by looping, waiting for A to either die and free up the network socket, or start listening on the filesystem socket. That might work, but looping doesn't feel right. I'm not sure if there are any problems lurking there. > If the bind to the network socket fails because something else is > listening, then it can try again on the file system and bail out with an > error if there's no writer. After all, that's not supposed to happen. That could work too. Looping has the advantage that if A dies just after binding the network socket, B will go back and try again, so the service will come up as long as B survives. But with supervision, it will get restarted anyway, so it's not really a big difference. So I guess there's no big advantage either way between the metaserver vs. keeping all the handoff functionality in one program. >> Another benefit of making the metaserver a separate program: you can >> also write a library for LD_PRELOAD that masks the listen() function >> to make existing programs use the metaserver instead of opening their >> listening sockets directly. > > That's a good one. But shouldn't that mask the bind() function? Probably, but it won't actually work either way, since the server needs to notice traffic on the filesystem connection. > As for the lease problem, couldn't metaserver just SIGTERM the existing > server? That suffers from the PID-recycling problem above. paul