From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2717 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Colin Booth Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit patches to fix compiler warnings on RHEL 7 Date: Sat, 30 Nov 2019 00:21:59 +0000 Message-ID: <20191130002159.GC17083@cathexis.xen.prgmr.com> References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55973"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: supervision@list.skarnet.org Original-X-From: supervision-return-2306-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Nov 30 01:22:06 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iaqWT-000ESY-03 for gcsg-supervision@m.gmane.org; Sat, 30 Nov 2019 01:22:05 +0100 Original-Received: (qmail 30589 invoked by uid 89); 30 Nov 2019 00:22:27 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 30582 invoked from network); 30 Nov 2019 00:22:27 -0000 Content-Disposition: inline In-Reply-To: <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2717 Archived-At: 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