From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32415 invoked from network); 2 Sep 2020 12:14:46 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 2 Sep 2020 12:14:46 -0000 Received: (qmail 9186 invoked by uid 89); 2 Sep 2020 12:15:06 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 9179 invoked from network); 2 Sep 2020 12:15:06 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re: possible s6-rc redesign Date: Wed, 02 Sep 2020 12:14:39 +0000 Message-Id: In-Reply-To: <3f51fff7-7e1c-3718-4b58-2f464cac4eb4@disroot.org> References: <877dtgtu1z.fsf@ada> <3f51fff7-7e1c-3718-4b58-2f464cac4eb4@disroot.org> Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudefledggeelucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedvgfevffeuleegvdektdffteegvdeiieefkeetgfeuheffheelheejhfevueeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >1. In order to provide the -sane- functionality of systemd, a system >needs to use linux-only interfaces. I am absolutely not saying that cgroup= s, >namespaces etc should be tightly integrated to a service manager/init syst= em. >Most of the work can be done on dedicated programs but they are needed >if the goal is feature-parity... Yes, that is very true, and a concern I've increasingly had: OSes are making *zero* coordination efforts for their interfaces, and software is increasingly relying on OS-specific interfaces. So it's becoming more and more difficult to write for Unix at large, and market fragmentation is becoming more obvious by the day. For the various engines of an init system, though, I'm not too worried. - The early boot is inherently not portable (s6-*linux*-init is called that way for a reason), but it's not a big or complex piece of code, and it's easy to adapt it to another OS as soon as one has a working knowledge of the details of init mechanisms on those OSes. - The supervision engine is portable, with a caveat. - The service manager is portable, even with dynamic event integration. What is *not* portable is the various listeners that produce events, but hooking a s6-rc-event call to them should not be difficult. The caveat for the supervision engine is, as you mentioned, cgroups and namespace management, for the sole reason that the Linux way of starting a process in a new namespace is contrary to the venerable Unix pattern of changing your own process state then exec'ing: in some cases you need involvement from the parent in changing the child's state. There is a patch that has been submitted to this list that does exactly that: tell s6-supervise to start the service in a new namespace. I have not applied this patch because I didn't want to introduce system- dependent features into s6, but with the way OSes are diverging, I might soon have to bite the bullet and change my stance on this. But apart from that misdesign from the Linux kernel, most OS-specific stuff can actually be done from inside services, in run scripts for instance, so engines can be kept portable. If OS-specific tools are needed to easily write service scripts, then those tools can be provided as a separate, OS-specific package - like an extension. In other words: policy is definitely not portable and needs a lot of extensions, but mechanism generally is, and I'm always starting with mechanism - I'll address Linux policy later. >2. Distributions that use systemd are slowly depending more and more on >these tendrils (great analogy btw :P). I do not think they will make the e= ffort >to get rid of them or provide alternate mechanisms to facilitate inclusion >of a different init system no matter how much better, cleaner and well- >designed it is. And s6-rc is all three of them IMHO. The only way to creat= e >pressure is a successful set of distributions that use other solutions... Yes, but do not underestimate the general efforts that are being done to have functionality outside of systemd. We're not the only bastion of opposition here :) Alternate mechanisms do exist for most of what=20 systemd does; distributions mostly migrate to the systemd way of doing things because it's more *convenient* to get the functionality from a single source than it is to piece it together from various bits. systemd is thriving on distribution laziness. But a distribution that is committed to not using systemd is (still) very much able to offer a lot of functionality, it just requires somewhat more effort. I don't expect to make it into Ubuntu or Red Hat right away. But if a lot of other distros out there are running a credible alternative with equivalent functionality, then at least users will have choice, and it will be impossible for systemd advocates to pretend that their chosen init system is inevitable. (insert Avengers: Endgame meme here) >I am not saying that policy should not be provided at all. I am saying tha= t they are > advantages if it is provided outside of the main project and downstreams = tailor it >to their specs. Possibly; that is honestly a packaging problem. It's a balance to find between flexibility and convenience. systemd and OpenRC have played the convenience card to the max and it has worked well for them; s6 has always played the flexibility card instead, and experts love that, but most people don't, especially when *no* policy is provided. :) If a package provides a set of init scripts, distributions will tailor it anyway. The RedHat /lib/systemd is not exactly the same as the Ubuntu one. The Alpine OpenRC scripts are not exactly the same as the Gentoo ones. It does not really matter where the policy is provided, but distros have made it very clear to me that they prefer having a working set to start with and to tailor to their needs, rather than having=20 nothing and needing to come up with everything themselves. If it's better for s6-frontend to be pure mechanism with a s6-frontend-policy package next to it, why not; I don't think anybody really cares as long as this=20 package exists. -- Laurent