On Tue, Sep 8, 2015 at 10:04 PM, Steve Litt <slitt_at_troubleshooters.com> wrote:
> Thanks Colin,
>
> I used Suckless-Init as PID1 and had Suckless-Init pass the baton to
> s6, using LittKit to enable service startup ordering in s6 and
> intermixing oneshots and longruns in s6.
>
> If I want to use s6 as my init, what do I do, just put into my Grub
> kernel line init=/usr/bin/s6 or whatever the s6 executable is?
>
You'd write a stage1 script similar to the one in
s6/examples/ROOT/etc/s6-init and write init=/path/to/that/file in your
grub line. Basically, that file does all your pre-supervision stuff,
then execs into s6-svscan, making your supervision root also your PID1
(sort of a best-of-both-worlds, and part of why s6-svscan is designed
to be so bomb-proof). The s6-linux-init-builder project on Laurent's
site automates generating that file.
>
> Is s6-rc something you add to s6, or is it a totally different thing?
>
Different-ish. You set up all your services (oneshots and longruns),
set their dependencies, and then compile a s6-rc dependency db and
service directory. After that point, if you want to do
dependency-aware service changes, you use s6-rc commands, and if you
need to take something down temporarily you use s6-svc or s6-rc
depending on if you want to pull down a set of services or not. It's
available to play with if you want to try it out (I've been using it
since it was first available in mid July, and we've squashed a LOT of
bugs). The program for updating a live system without some surgery
isn't available yet, which is why it hasn't been officially released,
but it totally works.
>
> Am I understanding you right that s6-rc enables you to order the
> startup of managed services, and intermingle those managed services
> with one-shots, as necessary?
>
Yup. A longrun can depend on a oneshot for environmental prep, which
can in turn depend on a different longrun having started and signaled
the system via the s6-ftrig-* notification framework.
>
> Also, am I understanding you correctly that, when used as an init, s6
> starts by running a stage 1 script, then execs itself into a
> supervision program, and when the user chooses to shut down, runs the
> shutdown script? If all of the above is true, it sounds challenging to
> run the wait loop, to reap zombies and receive signals, in the same
> PID1 that is the service manager. I guess I'll have to read the code.
>
When triggered, s6-svscan tells all s6-supervise processes to
terminate their services and then execs into another script to handle
shutdown proper. A reference script for stage 3 is also in the
examples directory. All that said, it isn't that bad combining the two
into your pid1, you just have to make sure you don't tell it to
terminate with s6-svscanctl. Honestly, runit or sysvinit have to
handle the same dual juggling of tasks - in runit's case though it
only needs to supervise one program (runsvdir) but sysvinit has to
supervise everything defined in its inittab so it's a similar level of
complexity (more actually, because sysvinit does more than just reap
and supervise).
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Wed Sep 09 2015 - 05:57:51 UTC