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" <[email protected]> wrote: > On Wed, Sep 2, 2015 at 3:07 PM, Laurent Bercot > <[email protected]> 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 >
