Similarly, I have two patches which I submitted to the mailing list in February which I would like to get merged:
http://www.mail-archive.com/supervision@list.skarnet.org/msg00500.html http://www.mail-archive.com/supervision@list.skarnet.org/msg00501.html It would be useful if Gerrit could respond to confirm whether he is still accepting patches to runit or planning to do any future releases. Regards, James -----Original Message----- From: supervision@list.skarnet.org [mailto:supervision@list.skarnet.org] On Behalf Of Avery Payne Sent: 16 June 2015 18:43 To: Buck Evan Cc: supervision@list.skarnet.org Subject: Re: patch: sv check should wait when svrun is not ready I'm not the maintainer of any C code, anywhere. While I do host a mirror or two on bitbucket, I only do humble scripts, sorry. Gerrit is around, he's just a bit elusive. On 6/16/2015 9:37 AM, Buck Evan wrote: > I'd still like to get this merged. > > Avery: are you the current maintainer? > I haven't seen Gerrit Pape on the list. > > On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan <b...@yelp.com > <mailto:b...@yelp.com>> wrote: > > On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne > <avery.p.pa...@gmail.com <mailto:avery.p.pa...@gmail.com>> wrote: > > > > On 2/17/2015 11:02 AM, Buck Evan wrote: > >> > >> I think there's only three cases here: > >> > >> 1. Users that would have gotten immediate failure, and no > amount of > >> spinning would help. These users will see their error delayed > by $SVWAIT > >> seconds, but no other difference. > >> 2. Users that would have gotten immediate failure, but could > have gotten > >> a success within $SVWAIT seconds. All of these users will of > course be glad > >> of the change. > >> 3. Users that would not have gotten immediate failure. None of > these > >> users will see the slightest change in behavior. > >> > >> Do you have a particular scenario in mind when you mention > "breaking lots > >> of existing installations elsewhere due to a default behavior > change"? I > >> don't see that there is any case this change would break. > <snip> > > Thanks for the thoughtful reply Avery. My background is also > "maintaining business software", although putting it in those terms > gives me horrific visions of java servlets and soap protocols. > > > I have to look at it from a viewpoint of "what is everything > else in the system expecting when this code is called". This > means thinking in terms of code-as-API, so that calls elsewhere > don't break. > > As a matter of API, sv-check does sometimes take up to $SVWAIT > seconds to fail. > Any caller to sv-check will be expecting this (strictly limited) > delay, in the exceptional case. > My patch just extends this existing, documented behavior to the > special case of "unable to open supervise/ok". > The API is unchanged, just the amount of time to return the result > is changed. > > > This happens because the use of "sv check (child)" follows the > convention of "check, and either succeed fast or fail fast", ... > > Either you're confused about what sv-check does, or I'm confused about > what you're saying. > sv-check generaly doesn't fail fast (except in the special case I'm > trying to make no longer fail fast -- svrun is not started). > Generally it will spin for $SVWAIT seconds before failing. > > > Without that fast-fail, the logged hint never occurs; the > sysadmin now has to figure out which of three possible services in > a dependency chain are causing the hang. > > Even if I put the above issue aside aside, you wouldn't get a hang, > you'd get the failure message you're familiar with, just several > seconds (default: 7) later. The sysadmin wouldn't search any more than > previously. He would however find that the system fails less often, > since it has that 7 seconds of tolerance now. This is how sv-check > behaves already when a ./check script exits nonzero. > > > > While this is > > implemented differently from other installations, there are > known cases > > similar to what I am doing, where people have ./run scripts like > this: > > > > #!/bin/sh > > sv check child-service || exit 1 > > exec parent-service > > This would still work just fine, just strictly more often. > >
