I'll just take that as a no. Thanks :) On Wed, Sep 2, 2015 at 5:50 PM, Laurent Bercot <[email protected]> wrote:
> 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 > >
