Re: runit patches to fix compiler warnings on RHEL 7

[Colin Booth <colin@heliocat.net>]

On Fri, Nov 29, 2019 at 03:09:01PM +0100, Jan Braun wrote:
> Hi,
> 
> Laurent Bercot schrob:
> >  - My opinion is that the most sustainable path forward, for runit
> > users who need a centrally maintained supervision software suite, is to
> > just switch to s6 - and it comes with several other benefits as well.
> 
> As a relatively new convert to supervision software, my reasons for
> preferring runit over s6 are, in order of priority:
> 
> 1) Debian ships with a working and maintained runit-init package. It
>    provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
>    Debian packages. s6-linux-init and s6-rc are not packaged in Debian.
runit-init is slowly becoming less functional and it wouldn't surprise
me if it fails entirely after Debian 10. As for s6-rc and s6-l-i, you
don't need either of those to emulate runit-init and if you do want them
you should talk to the current maintainer of s6 and execline about
adding them.

The rcS.d hooks can be covered with a shim program, though the LSB
compatibility layer in runit is pretty poor to start with and I tend to
suggest people avoid it if they can help it.
> 
> 2) runit has manpages. s6 has HTML. :(
Yeah, this sucks. I know Laurent isn't going to do it but I've been
meaning to take some time off and dedicate it to rewriting all of the
documentation into something that an compile into both mandoc and html.
> 
> 3) s6 executables are somehow worse named than runit's. This may be
>    highly subjective, but I can recall and recognize the runit commands
>    far easier than the s6 ones. Possibly it's the "s6-" prefix getting
>    in the way of my brain pattern matching on visual appearance of glyph
>    sequences.
>    This point is exacerbated by #2 and the number of s6 executables.
>    Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
>    s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
>    historical reasons, but sti
chpst is a monster of a program and at least with runscripts written in
execline it's generally easier to understand 3-4 process state
manipulators than a pile of chpst options.
> 
> 4) s6 seems more complex (hello execline!), and I don't (yet?) see any
>    benefit/feature I'd appreciate except minimizing wakeups.
s6 is more complex in terms of total bits than runit, but that
complexity brings objective benefits like having the supervision system
itself know when supervised services are ready and being able to query
the supervisor for that status. If you're talking about comparisons with
the supervisory portions of runit, besides the differences with chpst
mentioned earlier the two are pretty comparible. As for the execline
dependency, the only place where it's really required is if you use
s6-log processing directives though it's a pretty nice language for
writing run scripts in.
> 
> OTOH, an active and responsive upstream is obviously a big plus for s6.
> 
> >  - But again, I'm not impartial, and alternatives are a good thing.
> > So no matter what individual decisions are made, it would definitely be
> > a net positive if the exact state and workflow of runit could be
> > clarified, and if a real development/maintenance structure was in place.
> 
> Agreed.
> 
> Brainstorming possible ways forward:
> 
> A) Gerrit Pape becomes more active in maintianing runit, at least
>    acknowledging patches posted here.
> B) Somebody else steps in as (co-)maintainer.
> C) We get a dumping ground (wiki or somesuch) for patches to allow
>    - contributors to publish their patches (after discussing them here)
>    - users to easily find and download patches they'd be interested in
>    - Gerrit Pape to review and apply patches at his leisure when he
>      feels like making a new release.
> D) The maintainers of distros shipping runit work out a patch-sharing
>    scheme among them.
> 
> 
> Just my 0.02€, I hope it helps.
> 
> cheers,
>     Jan



-- 
Colin Booth