From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2734 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Steve Litt Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Date: Sun, 1 Dec 2019 21:47:52 -0500 Message-ID: <20191201214752.2ec0a81b@mydesk.domain.cxm> References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="110123"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision@list.skarnet.org Original-X-From: supervision-return-2323-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Dec 02 03:48:02 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 1ibbko-000STa-Cp for gcsg-supervision@m.gmane.org; Mon, 02 Dec 2019 03:48:02 +0100 Original-Received: (qmail 15809 invoked by uid 89); 2 Dec 2019 02:48:24 -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 15802 invoked from network); 2 Dec 2019 02:48:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To:References:X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding; s=default; d=troubleshooters.com; b=YZYYxqMWgZTStC5dPj/2nEwCnsij5p5fLGQjL+SxiKexFzVe/7CWJZEFkA1f9BQlajvqocDofg4flRPmYV6GB2aYQNPkQAQqk76YnTMCT5pDP7IL6CvTAhby3cOiRqZ+VVPDC2IWqewnVBbFK4JsdXGkCRFL1337FNhzn3xQQEE=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1575254873; bh=ZvhNYNi54SQHSA//W0rtRa9fGWw=; l=4301; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To: References:X-Mailer:MIME-Version:Content-Type: Content-Transfer-Encoding; b=IRdVY9eKudphF5z2cJJPZCB6eIL++68SnIGV9xlnHd8YLBRRRWqR+mGVkEE753aJz M5B+CQvdKAAoCKXsdAj9NOBbIKRdigpn01woUSeBDgqnIl9I3ww9Pg+JFHwWrWmcxZ rKnXxj4ybdC7d/3bZhSbDczj1KL2cpYnCT20f+To= X-Originating-IP: [72.188.224.222] In-Reply-To: X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2734 Archived-At: On Sat, 30 Nov 2019 10:15:27 +0000 "Laurent Bercot" wrote: > I hear you. Unfortunately, I have no control over what Debian does. > Debian isn't even able to ship a not-broken execline package, so I'm > at a loss on what to do with them. I'm working on a version of > execline that > they *might* accept to package correctly, but it's doubtful as long as > the people in charge are prejudiced against the "lots of small > binaries in /bin" approach. :( Would it be acceptable to you and them to put the binaries in /bin/s6 and then very early in the boot add /bin/s6 to the path? This isn't a lot different from what djb did with /command, except it's not off the root, which everyone seems to hate. [snip] > >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. > > This is very interesting. I thought that having a s6- prefix was a > *good* > thing, because I valued clarity above everything, and especially above > terseness. As a guy who has both daemontools and s6 installed on the same box, I thank you from the bottom of my heart for: 1) Prepending s6- to each command so they don't clash with djb's 2) Except for the s6-, naming them the same as djb's so I have less to remember. [snip] > > >4) s6 seems more complex (hello execline!), and I don't (yet?) see > >any > > benefit/feature I'd appreciate except minimizing wakeups. > > This, on the other hand, is a misconception that really needs to > disappear. Understanding execline is *not needed* to run s6. s6 > depends on execline in two places (there were more, but I scrapped > them because nobody used the commands that were involved): > - at build-time, in s6-ftrig-listen > - at run-time, in s6-log, for processor invocation > > Would entirely removing s6's dependency on execline help clear that > misunderstanding and help with s6 adoption? This could be made > possible by: > - duplicating el_semicolon() functionality in s6-ftrig-listen.c > (it's not elegant, but clearing the dep may be worth it) > - adding an alternative '?' processor directive to s6-log, that spawns > the processor using /bin/sh instead of execlineb. (The '!' directive > would still be there; processor invocations using '!' would just fail > if execline is not installed.) > > I don't like this, but if "execline" is a scarecrow that keeps people > away from s6 for no other reason than perception, it's a possibility. > Savvy users will still install execline for use in run scripts. I don't think it's necessary to remove the dependency unless ordinary users would be altering the code of s6-ftrig-listen or s6-log. A simple change change I think would do it is to change the documentation to imply that, for the *user*, execlineb is a way to get just a little extra whatever. Currently, when I read it, I thought I'd be missing a lot by using /bin/sh. > > s6-rc, however, absolutely cannot do without execline, since it uses > autogenerated execline scripts. But s6-rc is a different beast, that > requires a lot more involvement than s6 anyway, and that isn't needed > at all if we're just talking about runit-like functionality. Does the *user* need to code execline scripts, or is it just something the program does? If the former, then make a point that one doesn't need to use execline for s6-rc to be a very powerful startup system. If anybody would make an execline tutorial, that would help a lot. For a guy like me who only does procedural programming (C, C++, Pascal, Perl, Python, Ruby, Lua, etc), execline is difficult to understand. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr