On Mon, Feb 16, 2015 at 5:53 PM, Colin Booth <cathexis_at_gmail.com> wrote:
> On Mon, Feb 16, 2015 at 5:08 PM, Buck Evan <buck_at_yelp.com> wrote:
> > There's no dependant service involved.
> >
> > My check is running from outside the docker, racing against runit.
> >
> > Your workaround is valid, but still a workaround. My patch obviates the
> need
> > for the workaround.
> >
> Workaround or no, your patch changes the behavior of `sv check' to
> differ from the rest of the sv command set. Running `sv check' against
> any non-supervised directory, of which a not-yet supervised directory
> is a subset, should be, and is, a terminal event. This holds true for
> any of the sv commands, not just check.
Thanks Colin, that's the kind of feedback I was looking for. I do have to
admit that this would be a particular behavior of sv check.
If runit subscribes to "worse is better"[1] (and the design certainly seems
to be of the "New Jersey style"), this is a sacrifice of consistency for
simplicity; users don't need to write additional scripts when they run into
this edge case, and it makes the implementation no more complex.
More directly to your point, this is still a terminal event after my patch,
just delayed by $SVWAIT seconds.
If the goal of sv-check is (re?)interpreted to block until the service is
in a desirable state, this makes a lot of sense.
[1]
http://www.jwz.org/doc/worse-is-better.html
Received on Tue Feb 17 2015 - 19:26:50 UTC