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
@@ -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

Reply via email to