From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2403 Path: news.gmane.org!.POSTED!not-for-mail From: Colin Booth Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Added signal to have runsvdir wait Date: Fri, 30 Nov 2018 15:31:32 +0000 Message-ID: <20181130153132.slb3obk55yyk3jk2@cathexis.xen.prgmr.com> References: <_TKHR5bIsjf8l0o5ZZwcu3HDkPVtWHWHayW9gfdR97eweXFcW4XavY7cayFq0gHHa6gR3bKD1sO-GPwSVWoHOFw7jCbZIea-p04HCNwl4bs=@rem7.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543591772 27027 195.159.176.226 (30 Nov 2018 15:29:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 15:29:32 +0000 (UTC) User-Agent: NeoMutt/20170113 (1.7.2) To: supervision@list.skarnet.org Original-X-From: supervision-return-1994-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Nov 30 16:29:27 2018 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gSkjN-0006uN-V8 for gcsg-supervision@m.gmane.org; Fri, 30 Nov 2018 16:29:26 +0100 Original-Received: (qmail 31012 invoked by uid 89); 30 Nov 2018 15:32:01 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31005 invoked from network); 30 Nov 2018 15:32:00 -0000 Content-Disposition: inline In-Reply-To: <_TKHR5bIsjf8l0o5ZZwcu3HDkPVtWHWHayW9gfdR97eweXFcW4XavY7cayFq0gHHa6gR3bKD1sO-GPwSVWoHOFw7jCbZIea-p04HCNwl4bs=@rem7.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2403 Archived-At: On Tue, Nov 06, 2018 at 06:19:33AM +0000, Yanko wrote: > Hello, > > I was wondering if there was any interest in having runsvdir wait? > Similar to the HUP behavior but blocking. Sorru, I missed this email. I believe the lack of interest is that the official daemontools method for dealing with blocking on exit was to have your caller bring everything down, then signal the scanner to bail. Or in the case of systemic shutdown, term everything and then wait for each supervisor to exit independently. Additionally, runit is considered finished software by the author, so if it solves a problem for you great! But don't expect it to get upstreamed. If you have the flexibility to change supervisors, I'd suggest switching to s6. It already supports blocking shutdowns via the signal redirection mechanism, and has a richer support tooling ecosystem. > > I added another exit case that handles USR1, and waits for runsv(s) to > finish. See patch attached. (I'm not a fluent C programmer, so not > sure if I'm missing something). Like I said earlier, if it works for you that's awesome, but I think the runit community has alreaey built toolimg around handling the standard (albiet annoying) runit mechanisms. > > Thanks! > > Yanko Cheere! -- Colin Booth