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

From: Crest <>
Date: Thu, 3 Sep 2015 12:44:27 +0200

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
Received on Thu Sep 03 2015 - 10:44:27 UTC

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