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

From: Colin Booth <>
Date: Fri, 4 Sep 2015 09:24:45 -0700

On Wed, Sep 2, 2015 at 3:07 PM, Laurent Bercot
<> 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
> 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.


"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 Fri Sep 04 2015 - 16:24:45 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC