Re: runit patches to fix compiler warnings on RHEL 7

[Jeff <sysinit@yandex.com>]

30.11.2019, 01:22, "Colin Booth" <colin@heliocat.net>:
>>  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.

what about writing the docs in Perl's POD format or Markdown ?
it is easy to convert POD to html AND manpages (pod2(html,man))
and to deliver the generated docs in the source releases.

>>  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

totally agreed.

> 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.

this is more complicated to use, though.
therefore i personally prefer perp's approach of providing both:
the single process state manipulators and their combination into one
single tool ("run..." vs "runtool").

>>  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.

runit is dead, i recommend against using it at all, the only tools of interest
this supervision suite provides are "chpst" and "utmpset"
(though the latter is indeed not as powerful as it should to make it really
useful).

besides waking up to poll for rundir changes shutting it down really
sucks since it has problems closing the log files properly, i have not seen
this with any of daemontools encore, perp, and s6.

consider switching, daemontools encore and perp were not meant to run
as process #1, but they can be supervised by (Busy,Toy)Box- or SysV init easily.

daemontools encore's "svscan" utility wakes up to poll the rundir for changes
frequently, though, unlike s6 and perp it does not provide any option to only
do this on request (maybe by just listing for a given signal).

so the final conclusion and recommendation here is:
stop using runit for supervision (and as process #1) and switch to s6.