Re: sv check exit code not always helpful

From: Buck Evan <buck_at_yelp.com>
Date: Sun, 8 Feb 2015 17:49:07 -0800

My most immediate problem is that my client process is running sv check
before runit is even properly started.

My current solution is to wrap sv check and catch both the
cant-contact-supervisor, and ok:down-want:up conditions and count them as
down, and continue polling up to $SVWAIT seconds.

I believe this should properly be the behavior of sv check though.

On Sun, Feb 8, 2015 at 12:54 AM, Laurent Bercot <ska-supervision_at_skarnet.org
> wrote:

> On 08/02/2015 09:12, Colin Booth wrote:
>
> To get the functionality you want the dependent service should, as
>> part of its runscript, do something like 'sv status $otherservice |
>> grep "run"' to see if runsv considers the service to be running
>> followed by a call to 'sv check $service' to see if the service is
>> available.
>>
>
> Note, however, that there's a race condition: the service can die
> between the instant when the status is read and the instant when
> readiness is checked.
>
> Avoiding that race condition isn't very simple - that's the whole point
> of the libftrig mechanism in s6, and of the complexity of the s6-svwait
> and s6-svlisten1 programs. But even without a notification mechanism or
> precise state tracking, it would make sense for sv check (which is a
> "readiness polling" mechanism) to exit nonzero when the service is down,
> so it is never reported as ready when it isn't.
>
> --
> Laurent
>
>
Received on Mon Feb 09 2015 - 01:49:07 UTC