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

From: Buck Evan <buck_at_yelp.com>
Date: Thu, 3 Sep 2015 09:25:39 -0700

My apologies. I should have known you wanted an actual discussion.

An s6-checkhelper wrapper that implements exactly the above would make me
happy enough.
This is probably what I'll implement for myself in the meantime.

What I was picturing originally was the same as the runit contract: if a
./check exists, the framework does the polling for me.
I think it would be implemented to read the notification-fd file and the
(new) timeout-start files and do the Right Thing.
I'd probably define a default value for notification-fd (3?) but if you
want to error out when it doesn't exist and check does exist, that's fine
too.

That said, Crest's points bring another issue to mind.
The system I'm replacing with s6 defines a heartbeat for its services.
When the heartbeat fails, the service is restarted.
I suppose I'd define a mything-heartbeat service for each service that
needs this behavior?
I'm not sure how it would be implemented though.

At a guess:
If a service has a ./check script, I'll populate a thisservice-heartbeat
sub-service.
I'll write '3' to notification-fd if it doesn't exist.
The thisservice-heartbeat will run ./check at some interval and send
notification to notification-fd when it succeeds.
(Will sending many multiple up-notifications hurt anything?)
If ./check fails, I want to notify s6 that the service is no longer 'up',
and put it into a state where it will be restarted.
I'm not sure how I will do that bit.


On Thu, Sep 3, 2015 at 12:26 AM, Laurent Bercot <ska-supervision_at_skarnet.org
> 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?
>
> --
> Laurent
>
Received on Thu Sep 03 2015 - 16:25:39 UTC