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