supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Colin Booth <colin@heliocat.net>
To: supervision@list.skarnet.org
Subject: Re: Added signal to have runsvdir wait
Date: Fri, 30 Nov 2018 15:31:32 +0000	[thread overview]
Message-ID: <20181130153132.slb3obk55yyk3jk2@cathexis.xen.prgmr.com> (raw)
In-Reply-To: <_TKHR5bIsjf8l0o5ZZwcu3HDkPVtWHWHayW9gfdR97eweXFcW4XavY7cayFq0gHHa6gR3bKD1sO-GPwSVWoHOFw7jCbZIea-p04HCNwl4bs=@rem7.com>

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


      parent reply	other threads:[~2018-11-30 15:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06  6:19 Yanko
2018-11-06  6:22 ` Yanko
2018-11-30 15:31 ` Colin Booth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181130153132.slb3obk55yyk3jk2@cathexis.xen.prgmr.com \
    --to=colin@heliocat.net \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).