On Mon, Feb 16, 2015 at 5:53 PM, Colin Booth <[email protected]> wrote:
> On Mon, Feb 16, 2015 at 5:08 PM, Buck Evan <[email protected]> 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
