Re: s6: something like runit's ./check script

From: Buck Evan <buck_at_yelp.com>
Date: Tue, 8 Sep 2015 09:29:21 -0700

Putting them side by side for my own benefit, and normalizing Colin's
terminology and formatting:

Laurent's:
#!/command/execlineb -P
background -d
{
  fdmove 1 3
  forx -x 0 dummy { 1 2 3 4 5 6 7 }
  ifelse { ./check } { echo }
  foreground { sleep 1 }
  exit 1
}
fdclose 3
./run.real

Colin's:
#!/command/execlineb -P
fdmove -c 2 1
background -d
{
  fdmove 1 3
  loopwhilex -o 1
  ifelse { ./check } { echo }
  foreground { sleep 1 }
  exit 1
}
fdclose 3
./run.real

It looks to me like the only notable difference is Colin's 'fdmove -c 2 1'.
If I understand it, this is redirecting stderr to stdout, which would be
out of scope for a generalized polling helper. I assume it was written this
way because he combined the run and check scripts.

Open questions:

1) How long should the polling last? The forever-polling seems like it
would cause ever more orphaned polling processes as the service is
restarted. The runit precedent is seven seconds with an override. I think
a start-timeout file would be in line with current s6 design.

2) What should the poller do on timeout? Laurent's implementation would
give up quietly, and the service would simply never reach the up-and-ready
(U) state. I personally find this unacceptable. I'd like svstat to show
that the service is in a bad state in this case, although I don't know if
the concept of "bad state" currently exists in s6.

--phone is hard.
On Sep 8, 2015 9:01 AM, "Buck Evan" <buck_at_yelp.com> wrote:

> 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" <cathexis_at_gmail.com> wrote:
>
>>
>> On Sep 7, 2015 2:53 PM, "Buck Evan" <buck_at_yelp.com> 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!
>>
>
Received on Tue Sep 08 2015 - 16:29:21 UTC