Ok that solves my confusion. I think we all agree that a runit style sv-check doesn't fit in s6-packaging; we can safely call that topic closed.
Whether there should a an eased path to supporting services that need polling is another topic, I feel sure. Laurent is theoretically amenable to adding an auxiliary helper script for this purpose. I'd like to find consensus on the best practice in this case, which is why seeing your version of the same script will be informative. --phone is hard. On Sep 7, 2015 3:23 PM, "Colin Booth" <[email protected]> wrote: > > On Sep 7, 2015 2:53 PM, "Buck Evan" <[email protected]> wrote: > > > > Colin: > > > > Can we have a look at the script you're referring to? > > > > Are you making a point in favor of explicit ./check support in s6, or > against, or something else? I can't quite tell. > > > > --phone is hard. > > > Sorry! Explicit ./check-like behavior baked in to the ./run of the service > that needs checking as a way of translating from ./check polling into s6 > notification. Basically Laurent's example though in my specific case the > functionality test is directly in the run script instead of in a support > script since the test is super simple. > > In more general terms, I don't think s6 needs an `sv check' style test > added to it. Running those tests in a run script and translating the > results into notifications is a lot more powerful, and it simplifies the > between-service api. > > I'll post the script when I'm near my computer, phone here too. > > Cheers! >
