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

From: Buck Evan <>
Date: Wed, 2 Sep 2015 18:18:55 -0700

I'll just take that as a no.
Thanks :)

On Wed, Sep 2, 2015 at 5:50 PM, Laurent Bercot <>

> 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 - 01:18:55 UTC

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