On 03/09/2015 12:44, Crest wrote:
Starting an unsupervised background process is a brittle workaround.
It's not a brittle workaround, it's the exact right way to do it. You want to poll for service readiness until a certain timeout? well, then start a process that polls for service readiness until a certain timeout. The process can be 2 lines of shell. It doesn't get any simpler than this; I really don't see what the big deal is. Is it the fact that it's not integrated into s6-supervise that is bothering you? Well, I'm not integrating low-quality features into s6-supervise if they can be trivially implemented as a script. The script I suggested is not ad hoc: it's a straightforward, clean implementation of the feature. It can be refined if you want to be able to configure the number of tries and the polling period, which implies something like reading two environment variables; it's not exactly rocket science. Is it the fact that you want supervised, continuous polling? In that case, you're outside of the "readiness notification" territory and clearly in "service-specific monitoring" territory; the s6 notification mechanism is not, and cannot be, powerful enough to express all you can do with service-specific monitoring. The right way to proceed, as you wrote yourself, is to have a separate supervised service that performs the monitoring; but don't try and plug back the result of the monitoring into the s6 notification mechanism! Instead, just use that result directly to send the proper alerts, take the proper action, etc. This is entirely service-specific and s6 cannot help you there except in supervising your monitor. If you want your monitor to use s6-style notifications, you can: set up your own fifodir, have your alert managers subscribe to it, and have your monitor send s6-ftrig-notify messages to it: it will work, and you can define your own service-specific protocol, most likely richer and more complex than just "up, ready, down, ready", between the monitor and its subscribers. Just don't hijack s6-supervise's notification channel for that. The corner cases and things that can go wrong will only happen when you try to use a mechanism for a purpose it is not suited for. So don't do that.
The ./check script could fail after each test or include a polling loop, but it could also wait for more complex conditions e.g. wait for cluster to elect a leader or just implement the glue logic between s6's readiness notification protocol and the protocol(s) supported by the service.
AIUI, Buck's request was to be able to use ./check scripts from runit service directories as is with s6. Your suggestions here are changing the semantics: ./check is meant as a one-time polling action. If you need something more complex, script around ./check, or use something else entirely. TL;DR: - polling is bad and easy, anybody can do bad and easy, you don't need s6 to hold your hand for that - runit ./check support can be achieved in s6 via a trivial ./run wrapper and there's nothing hackish about that - long-term polling can be achieved via a separate service and there's nothing hackish about that - if you want to specifically monitor a daemon with commands that poll its state, don't involve the supervisor's notification mechanism, because it can't be tailored to your exact needs. You can still use the s6-ftrig-* mechanism if you want to publish your monitor's results. -- Laurent