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 2722 invoked from network); 22 Dec 2021 08:48:29 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 22 Dec 2021 08:48:29 -0000 Received: (qmail 1874 invoked by uid 89); 22 Dec 2021 08:48:52 -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 1867 invoked from network); 22 Dec 2021 08:48:52 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re: [announce] skarnet.org Winter 2021-2022 release Date: Wed, 22 Dec 2021 08:48:26 +0000 Message-Id: In-Reply-To: References: <20211221185417.120f440f@mydesk.domain.cxm> Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.2.1659.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvuddruddthedguddvhecutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuggftrfgrthhtvghrnhepffetkeduudefiefgkeevtdegkeegieeltdevfeeuieevheekhfdvueegveethfeknecuffhomhgrihhnpehskhgrrhhnvghtrdhorhhgpdhfohhsuggvmhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >I think trying to explain s6-linux-init + s6-rc through the lens of >runit's stages isn't a good idea. Carlos is correct - both here and in his explanation of s6-linux-init stages. When designing s6-linux-init, I kept runit's "stage" terminology because at the time it was a useful framework to see where things should go; but in retrospect, it was probably a mistake, prone to confusion, as exemplified by Steve's message. Even though, functionally, the "stages" in runit and s6-l-i have similarities, the way they're implemented and work under the hood is fundamentally different. runit's stage 1 and stage 2 are similar, their difference is only conventional: traditionally, runit runs all the oneshots in stage 1, and stage 2 is just an execution of runsvdir - but a setup where /etc/runit/1 is empty and all the oneshots are performed in /etc/runit/2 prior to the execution of runsvdir would work as well. s6-linux-init's stage 1 and stage 2 do not have the same similarity. Stage 1 is the early init, running as pid 1; this is only the /sbin/init script produced by s6-linux-init-maker, which executes into the s6-linux-init binary (which sets up the system and execs into s6-svscan); and users are not supposed to do anything with it. Stage 2, on the other hand, is the real boot sequence, running as not-pid-1; it is only run when stage 1 has completed, which means the system has an adequate long-running pid 1 process, a supervision tree, and a catch-all logger - all the basic infrastructure is in place and the services can be started. With s6-linux-init, stage 2 is where all the real work happens; and when the system's boot sequence is complete, the stage 2 script simply exits and the system keeps running until a shutdown command is issued. I want to keep the "stages" framing for s6-linux-init, because I think it is useful: these are qualitatively different parts of the init process. (There's a "stage 3" and a "stage 4" as well, at shutdown time: they're handled by the s6-linux-init-shutdownd daemon.) The framing is actually *more* useful here than in runit, where "stages" are only sequence points and the only real hardcoded meaning is that the system shuts down when /etc/runit/3 exits. >> The preceding is the best interpretation I could put together from >>https://skarnet.org/software/s6-rc/overview.html, >>https://skarnet.org/software/s6-rc/s6-rc.html, and discussions with >> you. What do I need to do to make the preceding sequence accurate? I don't know, honestly, Steve. At this point I cannot tell whether you're acting in good or bad faith. You seem to be talking about s6 and s6-linux-init, yet only mention the s6-rc documentation. You do not seem to have read the https://skarnet.org/software/s6-linux-init/quickstart.html page, which explains that s6-linux-init-maker is run offline, or the https://skarnet.org/software/s6-linux-init/s6-linux-init.html page, where the "Early preparation" part explains how stage 1 works. You do not seem to have watched my FOSDEM 2017 video at https://archive.fosdem.org/2017/schedule/event/s6_supervision/ where I describe the various duties of an init system and how the components in the s6 suite fill the boxes. Despite your claims to be interested, you have not put in s6 the tenth of the effort you put in runit. It's been going on for ages. You say you haven't paid much attention to the progress of s6, but over the years the fundamentals have not changed, they've been the same for a while now; the truth is that you have never paid much attention to s6 at all. You come to the list once in a while and ask a question that shows you are still lacking a basic understanding of s6, an understanding that comes from two hours of experimenting while having a browser open with 3-4 tabs to the documentation. And then you seem to ignore the answers, and go away until the next time when you come back just as helpless. You are clearly not dumb. So either you are a troll, or you need to get a grip and realize that if you're really interested, you can do the work of looking up and finding the relevant documentation, experimenting, and finally getting the reward of feeling the pieces of the puzzle fall into place, and acquiring the understanding that has eluded you for so long and that you seem to crave. As a technical writer, that is *your job*, so you can make the process easier for other people. s6 is not as complex as you seem to think it is, far from it. There are real, living people who understand how it works, and they're not all acne-ridden nerds living in a basement. The documentation may not be perfect, but it seems to be adequate. It lacks tutorials, yes, but I expect tutorials to be written by *people like you*, who could do a much better job of it than I ever would, if only they'd stop acting like damsels in distress at the first mention of a Unix pipe. And if you're not interested, or simply not enough to really get into it, that's okay too; you just need to own it and stop breadcrumbing. -- Laurent