From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2741 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Date: Mon, 02 Dec 2019 21:32:32 +0000 Message-ID: References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> <20191201214752.2ec0a81b@mydesk.domain.cxm> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="265424"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.36908.0 To: "supervision@list.skarnet.org" Original-X-From: supervision-return-2330-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Dec 02 22:32:34 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 1ibtJ4-0016v6-3e for gcsg-supervision@m.gmane.org; Mon, 02 Dec 2019 22:32:34 +0100 Original-Received: (qmail 2539 invoked by uid 89); 2 Dec 2019 21:32:59 -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 2532 invoked from network); 2 Dec 2019 21:32:59 -0000 In-Reply-To: <20191201214752.2ec0a81b@mydesk.domain.cxm> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudejhedgudehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucfrrghrrghmpehmohguvgepshhmthhpohhuthenucevlhhushhtvghrufhiiigvpedt Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2741 Archived-At: >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. s6 binaries aren't a problem for Debian; but apparently, execline binaries are. They're doing exactly that: they're storing execline binaries under /usr/lib/execline - except they're not putting that directory in the default PATH, they're only adding it to PATH when execlineb is invoked. Which breaks some s6 commands in older s6=20 versions, and breaks s6-rc commands (any version), because those assume that execline binaries can be found in their PATH, and don't call execlineb. It's completely acceptable to me to put binaries in a separate=20 directory. But said separate directory *needs* to be in the default PATH. If it is not, it means that those binaries are considered second-class citizens, and that is *not* acceptable - and even more importantly, it breaks things. >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. Yes, there are a good number of people, me included, who prefer that naming scheme. However, Jan's UX return is valid, and if I want to make s6 adoption as easy as possible, it needs to be taken into account too. >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. I think it's already the case, but I'll make a pass on the documentation to make it abundantly clear. >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. 1. execline is used *internally* by s6-rc, in autogenerated scripts.=20 The user doesn't have to know anything about it. 2. source oneshot up/down scripts are parsed by execlineb, so this is a place where users interact with it. However, the interaction can be made pretty minimal if the up/down script just calls a shell script stored somewhere else (typically /etc/init.d), which is common, and generally good, practice. For instance, the "source/network-interfaces/up" script could simply contain: /etc/init.d/network start and that's it. Technically, this is an execline script, made of two=20 words, but nobody needs to know that; and the complex logic of the script can=20 be implemented in the /etc/init.d/network program, which can be written in any language. Even in a compiled language, if you're a masochist. Advanced users can write more complex logic in the source/network-interfaces/up script itself, using execline binaries for control flow, etc. But it's by no means essential. For all intents and purposes, that script is just a small command line that execs into=20 another script, hosted wherever you want, written in whatever language you want. So I'd say the necessary interaction between s6-rc users and execline is really tiny. >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. Well, for one, the execline documentation is bad (it was my first real attempt at writing software documentation, and it shows), so revamping=20 it would probably help a lot. And second, there *are* execline tutorials online, you just haven't looked. -- Laurent