From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2770 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Colin Booth Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability Date: Sat, 21 Dec 2019 21:19:14 +0000 Message-ID: <20191221211914.GB12551@cathexis.xen.prgmr.com> References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> <20191221092639.p5iid3y3csmni4iw@klumpi.ignorelist.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="113929"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Laurent Bercot To: supervision@list.skarnet.org Original-X-From: supervision-return-2359-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Dec 21 22:19:19 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 1iim9e-000TVH-Ja for gcsg-supervision@m.gmane.org; Sat, 21 Dec 2019 22:19:18 +0100 Original-Received: (qmail 19941 invoked by uid 89); 21 Dec 2019 21:19:43 -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 19933 invoked from network); 21 Dec 2019 21:19:42 -0000 Content-Disposition: inline In-Reply-To: <20191221092639.p5iid3y3csmni4iw@klumpi.ignorelist.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2770 Archived-At: On Sat, Dec 21, 2019 at 10:26:39AM +0100, Jan Braun 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, > > If you're referring to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37 > then, well, you are fighting against POSIX. There's little choice for > Debian in the matter. Taking a hardline stance on such "legal" issues is > part of their identity as a distro. > It doesn't help that neither Adam nor Jakub read the documentation for the execline equivalents for cd, umask, or wait. That or they don't know what 'execs into' means. > > > but it's doubtful as long as > > the people in charge are prejudiced against the "lots of small binaries > > in /bin" approach. :( > > I don't think that's the real issue. POSIX saying "the cd/umask/wait > shell builtin must also be exec()able" is. Or execline's desire for > binaries with those names and different behaviour, depending on your > viewpoint. > Within the context of a shell the builtin will always* take precedence. *I'm sure there's a way to break your shell so that it doesn't but I don't know what it is and anyway it would be an impressively stupid thing to do. > > > [... 3) ...] > > The number of executables is a choice; I like to have more, smaller, > > executables than less, bigger ones. [...] > > So, I suppose it comes down to individual preference there. > > I agree, it's probably personal UI taste. To me, a good metric is the > "fanout" of possible options: > When I want to call something runit-related, I got > * chpst: change process state > ** -u: user > ** -n: nofiles > ... > - sv: manipulate a service > ** up > ** down > ** term > ... > - runsv supervision implemention > ** runsv one service > ** runsvdir a dir of services > > - sv- my custom scripts > ** sv-errors show the readproctitle logs > ... > > If any point in the tree, there's 7±2 children I can find by > tab-completing/glancing at a man page, then I can probably navigate the > whole thing pretty quickly. > > On the other hand: > | $ ls /usr/bin/s6* | cut -d- -f 2 | uniq | wc -l > | 39 > Even if there's still some related commands (e.g. 3x s6-sudo*), that > number is not coming down to a point where I can keep everything in > my head. > I think the real problem here is not that there are too many things prefixed s6- but that there isn't a super clear delineation between user-facing commands (s6-svc, s6-svscanctl, s6-svstat, s6-svok, s6-sudo, s6-tai64nlocal), the portions that belong directly to the supervisor (s6-svscan, s6-supervise, s6-ftrigrd), and the parts that are only used occasionally or are meant to be called from inside of scripts (most everything else). FWIW, runit is actually worse in terms of separating out what goes where from a documentation standpoint, however there are only nine programs shipped with runit so it matters less. > > But outside of supervision, I notice that you are reimplementing a > lot of small programs. As long as they're mostly command-line compatible > with their inspiration, I think such a "s6" executable would enable a > nicer UI for s6-{linux,portable}-utils and the s6 djb reimplementations: > > Have your binaries in /usr/lib/s6/ (or wherever), and named without the > "s6-" prefix. Have a "s6" binary multiplexing to these on its first > argument. That way, a user can choose any of: > > | $ s6 cat foo > | > | $ PATH="/usr/lib/s6/:$PATH" > | $ cat foo > | > | # ln -sf /usr/lib/s6/cat /bin/cat > | $ cat foo > > (And possibly a s6-cat compatibility symlink somewhere.) > This is similar to busybox (except for the reverse goal :) and allows > individual customization, while keeping /bin/ uncluttered by default. > Have you ever considered slashpackage ;) In all seriousness though this, with the exception of dropping the s6- prefix (and the prefix-appender binary I guess), is what slashpackage does. /bin stays uncluttered, commands end up in a PATH-able place, and if you want to surprise any systemic shell scripts you have you can symlink in replacements to the default PATH. > > > 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. > > Yes. But since you are mentioning it, that was another of my "s6 seems > more complex" issues. runit goes from "start the supervisor manually" to > "be pid 1" with very little effort. See runit(8). > Or https://www.unix.com/man-page/debian/8/runit/ I guess. ;-P > > s6-linux-init and s6-rc seem extremely complicated in comparison. And > it's not clear to me how much of that complexity is optional, and what > it might buy me. Maybe a better high-level overview document might help > there. > If you're trying to have a drop-in replacement for runit(8) then s6-linux-init (specifically s6-linux-init-maker) is all you really need to figure out, and then only when building out a system. Then you need to do some editing of the generated and relocated scripts to get it to work right. Of course, setting up runit's 1 takes a bit of doing if you want it to do anything else than put you into singleuser. If you want a system that's modern (with service dependencies and all that) you need to set up s6-rc but it is by no means a requirement. s6-l-i on its own gets you a pretty compact boot system that's pretty well suited for running purpose built VMs since you can handle all the dependency tracking and shutdown protection using tools provided in s6 alone. As for an overview, the why, overview, and quickstarts in s6-linux-init should cover it. But for those who prefer it in email format, what you get is: the supervisor as pid 1, hpr (halt/poweroff/reboot) interfaces that understand how to work with the service model, direct IPC using common s6 interfaces instead of the ghastly interfaces like stopit, ctrlaltdel, reboot, nosync, a safety net of having a running supervisor (and as such a running getty) during shutdown, and so on. runit is impressively technically simple but that technical simplicity begats workarounds and a lack of safety when it comes to the lifecycle of a full system and most of the added design complexity around s6-l-i is mostly there to make sure it can handle shutdown in a clean way. FWIW, the original design of s6 followed much closer to the runit design, though with stage1 execing into s6-svscan (instead of forking it), stage2 only handling post boot initialization tasks (instead of those tasks and then the supervisor), and stage3 also being pid1 (via s6-svscan's finish script). (speaking of walls of text). > > P.S: I stumbled over this execline oddity: > | dollarat -0 -d a # separates by \0 > | forbacktickx -0 -d a var {gen...} loop... # splits on a > IMHO, both should be an error, but at least treat them the same. > As per the docs for forbacktickx: -0 : accept null characters from gen's output, using them as delimiters. If this option and a -d option are used simultaneously, the rightmost one wins. Cheers! -- Colin Booth