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

From: Buck Evan <buck_at_yelp.com>
Date: Mon, 7 Sep 2015 14:53:47 -0700

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.
On Sep 4, 2015 9:44 AM, "Colin Booth" <cathexis_at_gmail.com> wrote:

> On Wed, Sep 2, 2015 at 3:07 PM, Laurent Bercot
> <ska-supervision_at_skarnet.org> wrote:
> > echo 3 > notification-fd
> >
> > mv run run.real
> >
> > cat > run <<EOF
> > #!/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
> > EOF
> >
> > chmod 755 run
> >
> > Untested, but that should report readiness if ./check succeeds
> > within 7 attempts at running it, with 1 second between attempts.
> > How it works is left as an exercise to the reader. %-P
> >
> That's pretty much what I ended up doing with my s6-rc stuff for
> faking up s6 notifications from udev because I didn't want to make a
> listener for the systemd notification stuff. The only major
> differences are that I used loopwhilex (I like forever blocking), and
> I embeded what would be in the check script straight into that ifelse
> block. Oh, I also didn't break out run into run and run.real because
> the run script would essentially be a one-liner.
>
> This isn't terribly hacky beyond the whole "converting between polling
> and notification" part and as a generic notification enabling wrapper
> is pretty good. In a non-s6 context, blocking dependent services by
> polling the first service's check script in a loop is basically all
> you have for ordering mechanics, and using a similar mechanism to wrap
> a self-check that reports in to s6's notification system is an obvious
> extension of that same pattern when running under s6. Especially since
> it then lets you get rid of the cross-service check script dependency
> and instead just have the second service block with s6-svwait.
>
> Personally, I never liked the check mechanisms in runit, or really any
> of the LSB compatibility stuff. Doing a bit more work up-front to hook
> into the notification system is worth it to me to be able to isolate
> the use of polling tests to the run script in question and let
> everyone else use the notification framework. This works in my case
> because practically the only time I use things like `sv check' is when
> I'm trying to block the immediate return from sv after starting
> something and notification is a lot more friendly on the process
> scheduler when you're seriously beating up a computer.
>
> Cheers!
> -Colin
>
> --
> "If the doors of perception were cleansed every thing would appear to
> man as it is, infinite. For man has closed himself up, till he sees
> all things thru' narrow chinks of his cavern."
> -- William Blake
>
Received on Mon Sep 07 2015 - 21:53:47 UTC