Re: sv check exit code not always helpful

From: Buck Evan <buck_at_yelp.com>
Date: Mon, 9 Feb 2015 15:59:37 -0800

James, I've taken your patch and also "fixed" the "up, want down" case as
well.
I've tried pretty hard to match surrounding style, in the hope that this
can be upstreamed.

https://github.com/bukzor/runit/issues/1#issue-57074153

From: Buck Evan <buck_at_yelp.com>
Date: Mon, 9 Feb 2015 14:08:48 -0800
Subject: [PATCH] the service is not ready if the current state is not wanted

fixes bukzor/runit#1

---
 src/sv.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/sv.c b/src/sv.c
index 7c6f6ed..701912c 100644
--- a/src/sv.c
+++ b/src/sv.c
_at__at_ -227,7 +227,11 @@ int check(char *a) {
       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':
+      switch (svstatus[17]) {
+      case 'u': if (!pid || !checkscript()) return(0); break;
+      case 'd': if (pid) return(0); break;
+      }
     case 't':
     case 'k':
       if (!pid && svstatus[17] == 'd') break;
On Mon, Feb 9, 2015 at 9:50 AM, Buck Evan <buck_at_yelp.com> wrote:
> +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 - 23:59:37 UTC