supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Jan Braun <janbraun@gmx.de>
To: Laurent Bercot <ska-supervision@skarnet.org>
Cc: supervision@list.skarnet.org
Subject: Re: runit patches to fix compiler warnings on RHEL 7
Date: Fri, 29 Nov 2019 15:09:01 +0100	[thread overview]
Message-ID: <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> (raw)
In-Reply-To: <em45d91edb-d7ec-463a-b4c4-10f49710c966@elzian>

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

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.

2) runit has manpages. s6 has 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 still.

4) s6 seems more complex (hello execline!), and I don't (yet?) see any
   benefit/feature I'd appreciate except minimizing wakeups.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2019-11-29 14:09 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 21:43 J. Lewis Muir
2019-11-27 20:33 ` J. Lewis Muir
2019-11-28  7:59   ` Ben Franksen
     [not found]   ` <ecdf4d8f-93f6-3f9f-b84c-351fa91c7f02@uni-bremen.de>
2019-11-28 19:04     ` Laurent Bercot
2019-11-28 20:39       ` Steve Litt
2019-11-28 22:17         ` runit or s6 (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-11-29 14:09       ` Jan Braun [this message]
2019-11-29 21:46         ` runit patches to fix compiler warnings on RHEL 7 Dewayne Geraghty
2019-11-30  1:22           ` Colin Booth
2019-11-30  0:21         ` Colin Booth
2019-11-30  3:14           ` Steve Litt
2019-11-30 13:32           ` Jeff
2019-11-30 13:46             ` Jeff
2019-11-30 10:15         ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-11-30 14:32           ` Jeff
2019-11-30 18:58             ` Laurent Bercot
2019-12-02 12:07               ` Jeff
2019-12-02 22:20                 ` Laurent Bercot
2019-12-02  2:47           ` Steve Litt
2019-12-02  3:37             ` s6 usability Dewayne Geraghty
2019-12-02 10:24               ` fungal-net
2019-12-02 21:32             ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-12-02 23:17               ` s6 usability Samuel Holland
2019-12-03 22:10                 ` Steve Litt
2019-12-21 11:49                   ` Jan Braun
2019-12-04 12:15                 ` Jonathan de Boyne Pollard
2019-12-04 21:02                 ` Laurent Bercot
2019-12-04  1:30             ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Casper Ti. Vector
2019-12-21  9:26           ` s6 usability Jan Braun
2019-12-21 18:36             ` Guillermo
2019-12-21 21:19             ` Colin Booth
2019-12-22  1:05               ` Jan Braun
2019-12-22  8:30                 ` Colin Booth
2019-12-21 23:46             ` Laurent Bercot
2019-12-22  5:53               ` Jan Braun
2019-12-22 20:33               ` Steve Litt
2019-12-22 23:20                 ` Laurent Bercot
2019-12-23  1:28                   ` Oliver Schad
2019-12-23  9:14                     ` Laurent Bercot
2019-12-23 10:15                     ` Jonathan de Boyne Pollard
2019-12-24  0:18                       ` Oliver Schad
2019-12-23  1:57                   ` Steve Litt
2019-12-23  9:00                     ` Laurent Bercot
2019-12-22 23:47                 ` Dewayne Geraghty
2019-12-04 11:36         ` runit patches to fix compiler warnings on RHEL 7 Jonathan de Boyne Pollard
2019-12-04 16:40           ` J. Lewis Muir
2019-12-04 20:48             ` Laurent Bercot
2019-12-04 21:32               ` J. Lewis Muir
2019-12-04 21:06             ` Steve Litt
2019-12-04 21:50               ` Laurent Bercot
     [not found]                 ` <20191205132736.7f501460@puter>
2019-12-08 19:10                   ` Laurent Bercot
2019-12-02 17:57       ` J. Lewis Muir
2019-12-02 21:06         ` J. Lewis Muir
2019-12-02 22:22           ` Laurent Bercot
2019-12-02 21:58         ` Laurent Bercot
2019-12-03 10:57           ` Benjamin Franksen
2019-12-04 10:43       ` Jonathan de Boyne Pollard
2019-12-02 17:13     ` J. Lewis Muir
2019-12-04 11:13       ` Jonathan de Boyne Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com \
    --to=janbraun@gmx.de \
    --cc=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).