From my own experience setting up s6 on a Linux distro where it isn't supported:
> Before first installation, back up /sbin/init so if things go wrong it's easy to boot with your prior init. Before running any s6 components, do all the correct config so that the s6-rc-compile program to produce a proper s6-rc. Do this every time you add or subtract services.
Correct.
> Grub boots to s6-linux-init-maker, which creates several things, including a new /sbin/init, and then execs /sbin/init
s6-linux-init maker is actually run by the user as part of the process
of setting up s6. It generates a /etc/s6-linux-init/current folder,
including the contents of an initial, barebones /run folder
(./run-image/), the "stage" scripts
(./scripts/rc.{init,shutdown,shutdown.final}) and ./bin subfolder with
poweroff, shutdown, halt, reboot, and the stars of the show, init and
telinit. The latter must be symlinked or copied to /sbin. A possible
way to not overwrite the current init is symlinking them with a
prefix, for instance /sbin/s6-init →
/etc/s6-linux-init/current/bin/init.
> * /sbin/init does the necessary stuff about signals and the like, and then forks the stage1 script
I think trying to explain s6-linux-init + s6-rc through the lens of
runit's stages isn't a good idea.
Unlike runit, the stage 1 is directly spawned by the kernel as init.
In addition to handling signals, it sets up an initial environment,
mounts /run as an RAM filesystem and copies the contents of
/etc/s6-linux-init/current/run-image to it, and it then forks, marking
the beginning of stage 2.
In the second stage (after forking), the PID 1 becomes (execs) an
s6-svscan instance watching over /run/service, and the child ("PID 2",
so to speak) calls s6-rc to bring services up. First "s6-rc-init",
which will symlink service directories (with a down file) from the
compiled s6-rc database to /run/service, including an s6-sudo
responsible for spawning oneshots, and after that "s6-rc -u change
default", to bring the default bundle of services up.
Stage 1 is shrunk in s6, and stage 2 takes more responsibilities.
Stage 3 isn't even handled by PID1 - it's an independent
s6-linux-init-shutdownd service (which, like the catch-all logger, is
included as part of /etc/s6-linux-init/current/run-image when you run
s6-linux-init-maker, so you don't need to worry about it when
compiling the s6-rc database).
> * When s6-rc-init completes, the stage 2 script execs s6-rc, so s6-rc is PID 1. s6-rc supervises s6-svscan, which supervises all the other services, both longrun and shortrun.
s6-svscan is the PID 1, and supervises longrunning services.
s6-rc is itself a short lived program, living only long enough to
bring services up or down (though, it reports if oneshots fail).
Since it's not a permanent process, it relies on s6-svscan to keep
restarting services and not letting the machine's state change.
Oneshots aren't really supervised, it's expected that, if an admin
wants to undo what a oneshot did, they'd call "s6-rc -d change
$oneshot".
Em ter., 21 de dez. de 2021 às 20:54, Steve Litt
<slitt_at_troubleshooters.com> escreveu:
>
> Hi Laurent,
>
> Congratulations on your updated software!
>
> I searched through my execline documentation page
> ( http://troubleshooters.com/linux/execline.htm ) to see whether
> revisions were needed. They weren't, but I found and fixed several
> errors on that page.
>
> I've been doing other things and haven't paid much attention to the
> progress of s6. I haven't found any simple documentation on it. Let me
> see if I understand...
>
> * Before first installation, back up /sbin/init so if things go
> wrong it's easy to boot with your prior init
>
> * Before running any s6 components, do all the correct config so that
> the s6-rc-compile program to produce a proper s6-rc. Do this every
> time you add or subtract services
>
> * Grub boots to s6-linux-init-maker, which creates several things,
> including a new /sbin/init, and then execs /sbin/init
>
> * /sbin/init does the necessary stuff about signals and the like, and
> then forks the stage1 script
>
> * When the stage 1 script completes, /sbin/init execs the stage 2
> script, so the stage 2 script is PID1 now
>
> * The stage 2 script forks s6-rc-init
>
> * When s6-rc-init completes, the stage 2 script execs s6-rc, so s6-rc
> is PID1
>
> * s6-rc supervises s6-svscan, which supervises all the other services,
> both longrun and shortrun.
>
> 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?
>
> Thanks,
>
> SteveT
>
> Steve Litt
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
>
>
>
> Laurent Bercot said on Tue, 21 Dec 2021 08:19:38 +0000
>
> > Hello,
> >
> > New versions of all the skarnet.org packages are available.
> >
> > The changes are, for the most part, minimal: essentially, the new
> >versions fix a bug in the build system that made cross-building under
> >slashpackage more difficult than intended. Very few people should
> >have been impacted by this bug.
> > Some packages had a few more bugfixes; and some packages have
> >additional functionality. No major update; no compatibility break.
> >
> > The new versions are the following:
> >
> >skalibs-2.11.1.0 (minor)
> >nsss-0.2.0.1 (release)
> >utmps-0.1.1.0 (minor)
> >execline-2.8.2.0 (minor)
> >s6-2.11.0.1 (release)
> >s6-rc-0.5.3.0 (minor)
> >s6-portable-utils-2.2.3.4 (release)
> >s6-linux-utils-2.5.1.7 (release)
> >s6-linux-init-1.0.7.0 (minor)
> >s6-dns-2.3.5.3 (release)
> >s6-networking-2.5.1.0 (minor)
> >mdevd-0.1.5.1 (release)
> >bcnm-0.0.1.5 (release)
> >dnsfunnel-0.0.1.3 (release)
> >smtpd-starttls-proxy-0.0.1.1 (release)
> >
> > Dependencies have all been updated to the latest versions. They are
> > not
> >strict: libraries and binaries may build with older releases of their
> >dependencies, although this is not guaranteed.
> >
> > You do not need to recompile your s6-rc service databases. To make
> > use
> >of the new s6-linux-init functionality, however, you will have to
> >recreate your run-image.
> > You do not need to restart your supervision tree, unless you're
> >deleting
> >your old s6 binaries.
> >
> > Details of minor package changes follow.
> >
> >* skalibs-2.11.1.0
> > ----------------
> >
> > - New function: opendir_at()
> >
> >
> >* utmps-0.1.1.0
> > ------------
> >
> > - New binary: utmps-write, a generic utmp client that can write
> >user-crafted records to the utmp and/or wtmp databases.
> >
> >
> >* execline-2.8.2.0
> > ----------------
> >
> > - New -s option to the case binary, enabling fnmatch() (shell)
> >expression matching instead of regular expression matching.
> >
> >
> >* s6-rc-0.5.3.0
> > -------------
> >
> > - Bundle contents are now read in a "contents.d/" subdirectory, one
> >file per content, instead of one per line in a "contents" file. In
> >the same way, service dependencies are now read in a "dependencies.d/"
> >subdirectory, one file per dependency. Old "contents" and
> >"dependencies" files are still supported, but deprecated. This change
> >allows better integration of s6-rc service definitions with package
> >managers.
> >
> >
> >* s6-linux-init-1.0.7.0
> > ---------------------
> >
> > - New -S option to s6-linux-init-maker, forcing a sync on halt even
> >in a container.
> >
> >
> >* s6-networking-2.5.1.0
> > ---------------------
> >
> > - SNI wildcarding is implemented, as well as a workaround for a
> >bearssl bug causing errors on certificate signatures in certain cases.
> >
> >
> > Enjoy,
> > Bug-reports welcome.
> > And happy holidays to you all!
> >
> >--
> > Laurent
> >
Received on Wed Dec 22 2021 - 04:39:46 CET