Re: sv check exit code not always helpful

From: Buck Evan <buck_at_yelp.com>
Date: Mon, 9 Feb 2015 09:50:02 -0800

+1

I usually assume usability issues like these exist simply because the
original dev didn't encounter them, until proven otherwise.

On Mon, Feb 9, 2015 at 2:17 AM, James Byrne <james.byrne_at_origamienergy.com>
wrote:

> On 09/02/15 01:49, Buck Evan wrote:
>
>> 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.
>>
>
> I had the same problem, and posted a possible solution, and some questions
> about it, to this list a few weeks ago (Jan 14), but I didn't really get a
> lot of feedback on whether or not this was the right change. Please feel
> free to try it though, as it seems to work for me.
>
> My solution is to make the following change to sv.c:
>
> --- old/sv.c 2014-08-10 19:22:34.000000000 +0100
> +++ new/sv.c 2015-01-14 14:29:31.384556297 +0000
> _at__at_ -227,7 +227,7 @@
> if (!checkscript()) return(0);
> break;
> case 'd': if (pid || svstatus[19] != 0) return(0); break;
> - case 'C': if (pid) if (!checkscript()) return(0); break;
> + case 'C': if (!pid || !checkscript()) return(0); break;
> case 't':
> case 'k':
> if (!pid && svstatus[17] == 'd') break;
>
> With this change, "sv check" works in a much more useful way. If all the
> services specified are up it will exit with exit code 0, and if not it will
> wait until the timeout for them to come up, and return a non-zero exit code
> if any are still down.
>
> I would still appreciate any feedback on this, and especially on whether
> there is any reason for the existing behaviour of 'sv check'.
>
> James
>
Received on Mon Feb 09 2015 - 17:50:02 UTC