On 03/09/2015 01:55, Buck Evan wrote:
> That seems like a lot of brain surgery for this essential feature.
Brain surgery? That's just spawning a process running ./check up to
seven times and sending the notification newline to the right fd if
one of the invocations succeeds. That's exactly what "sv check" does,
except it plugs into s6-supervise's notification mechanism so you can
wait for service readiness with s6-svwait.
> I think I'll spawn such a background process from my framework by default
> if ./check exists.
That was kinda the reason why I wrote my suggestion as a ./run wrapper:
you can include it in your automation.
> I suppose you have no inkling of making ./check an s6 feature?
I don't understand what you're asking for.
./check is not an s6 feature and it's not a runit feature either.
./check is a service-dependent user-written script that polls the
service for readiness; that's all it is, and you don't need
supervisor support to write it.
The runit feature is "sv check", which simply loops around ./check and
exits 0 when it does. That's 2 lines of the above execline script; it would
also be 2 lines of shell. The other lines are there to plug the result into
the s6-supervise notification-fd mechanism, which is exactly what you
wanted; and you can then use "s6-svwait -uwU service" whenever you want to
wait until your service is up and ready.
Notification is superior to polling in every way. The whole *point* of
the notification system is to avoid polling. And if a specific service
only supports polling for readiness, you can still use the notification
system as shown above, by adding a trivial wrapper to the run script.
The "s6 feature" is basically "I made s6 flexible enough that you can
already do what you're asking for".
--
Laurent
Received on Thu Sep 03 2015 - 00:50:49 UTC