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_at_list.skarnet.org/msg00500.html
>
> http://www.mail-archive.com/supervision_at_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_at_list.skarnet.org [mailto:supervision_at_list.skarnet.org] On Behalf Of Avery Payne
> Sent: 16 June 2015 18:43
> To: Buck Evan
> Cc: supervision_at_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 <buck_at_yelp.com
> > <mailto:buck_at_yelp.com>> wrote:
> >
> > On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
> > <avery.p.payne_at_gmail.com <mailto:avery.p.payne_at_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.
> >
> >
>
Received on Thu Jun 18 2015 - 14:54:21 UTC