supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: supervision@list.skarnet.org
Subject: Re: [announce] skarnet.org Winter 2021-2022 release
Date: Wed, 22 Dec 2021 08:48:26 +0000	[thread overview]
Message-ID: <em9b8a745e-7a00-4aa0-b3ec-7d1550c6cea5@elzian> (raw)
In-Reply-To: <CAN09KnJh5T1tYc2S6WsxVB7hu0HURJ3yH4KhMwRCW+3AQwT9zQ@mail.gmail.com>

>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


  reply	other threads:[~2021-12-22  8:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21  8:19 Laurent Bercot
2021-12-21 23:54 ` Steve Litt
2021-12-22  3:39   ` Carlos Eduardo
2021-12-22  8:48     ` Laurent Bercot [this message]
2021-12-22 10:18       ` Casper Ti. Vector

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=em9b8a745e-7a00-4aa0-b3ec-7d1550c6cea5@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).