On 03.09.2015 09:26, Laurent Bercot wrote: > On 03/09/2015 03:18, Buck Evan wrote: >> I'll just take that as a no. > > I honestly don't understand what a "yes" would entail. > What functionality would you like to see, what changes > to the current s6 behaviour would you like to see? >
Starting an unsupervised background process is a brittle workaround. Yes notification is more elegant, saves resources and if done wright a lot faster than polling at a sane interval, but a lot of services lack notification support yet are easy to poll with trivial scripts along the lines of `sockstat -l46p $PORT` or `nc -z localhost $PORT`. The load polling with such a script every 100ms or some adds to a system is miniscule compared to resourced required by service to be polled and no problem for your desktop or *nix running a few dozen services on physical hardware. Battery powered devices or virtual systems have less spare CPU cycles to waste and profit from the improved efficiency of proper notification. The lower latency is nice to have but far from critical for most use cases. Adding reliable readiness notification to a service requires the admin to add a polling service e.g. /service/$FOO-check from /service/$FOO/run, inform s6 about the new service, pass the notification file descriptor to from /service/$FOO/run to /service/$FOO-check/run and clean up afterwards. All of this would be a collection of ad hoc scripts in execline or shell with lots of corner cases to get wrong. And more trouble that it's worth to most admins I presume. It would be nice for s6-supervise to support taking its notification from ./check instead of ./run and supervise ./check until it notifies s6-supervise that its job is done. 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.