+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 <[email protected]> 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 > @@ -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 >
