It would be good if that URI appeared on the runit homepage: http://smarden.org/git/runit.git
On Thu, Jun 18, 2015 at 6:24 PM, Buck Evan <b...@yelp.com> wrote: > Thanks Gerrit. > > How would you like to see the layout, build process look? Maybe there's an > example project you like? > If it's easy enough for me to try, I'd like to. > > On Thu, Jun 18, 2015 at 7:54 AM, Gerrit Pape <p...@smarden.org> wrote: > >> Hi all, >> >> I'm around, but currently not very active in my open source activities. >> >> runit started in 2001 and was tracked in CVS. After I took over Debian >> maintainership of git in 2005, I converted the repository to git. The >> complete history is available since then >> >> git clone http://smarden.org/git/runit.git/ >> >> Every here and then I think about doing some work on runit, like >> integrating patches, but find the file layout in the repo, the build and >> installation process, so archaic that I stop again, most of the time. >> It's about 13 years old.. >> >> Those two things are the two top items on my TODO list. >> >> Regards, Gerrit. >> >> >> On Thu, Jun 18, 2015 at 10:35:45AM +0000, James Byrne wrote: >> > 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. >> > > >> > > >> > >> > >
