On 06/01/2015 02:03, James Powell wrote:
> The initial init bootscript that I'm currently drafting is in
> execline using the template provided by Laurent. I was going to take
> the advice on using /bin/sh rather than /bin/execlineb but I recanted
> that decision due to the fact I wanted the using the FIFO handling
> execline provides.
Far be it from me to discourage you from your noble quest ! But
you could write it in sh and just use the 'redirfd' command from
execline, which does the FIFO magic.
That said, performing multiple chain loads in shell is a pain,
and you'd have to write something like
"... ; exec redirfd -wnb 1 fifo /bin/sh -c '...'" which quickly
becomes a quoting nightmare for the second part of the script. So
maybe learning execline is the right choice. ;)
> If I am reading things correctly, assumingly, init-stage1 using the
> template, I only need to correct the paths and include any mounts of
> virtual kernel file systems not listed as well as get cgroups ready,
> and stage any core one-time services like copying core service
> scripts to the service scan directory on the tmpfs, correct, before
> passing off to init-stage2 to load drivers, start daemons, etc.?
That is correct - it's how I designed the example init-stage1 in
the s6 tarball.
It is not the only way to proceed, but I find it the safest way,
even safer than runit, because it puts the supervision infrastructure
in place extremely early on.
The idea is that unlike svscan and runsvdir (that poll their scan
directory every five seconds no matter what), s6-svscan can be told
to scan for services immediately (with the s6-svscanctl -a command).
So it's possible for a s6-based system to start s6-svscan on an
empty, or nearly empty, scan directory, to have it running as early
as possible; then to populate the scan directory with other
services, and trigger s6-svscan so those services start immediately.
So, stage 1 just becomes:
a) Do what is strictly necessary to prepare the scan directory for
s6-svscan
b) Fork a background process that will block until s6-svscan is
guaranteed running
c) exec into s6-svscan, which will run as process 1 until shutdown.
a) involves virtual filesystems, maybe cgroups, and setting up
a few basic services in the scan directory: s6-svscan's own logger,
udev, and an early getty for debugging, for instance.
b) can be done in different ways, but I've found it simple to just
open s6-svscan's logging FIFO for writing in the *normal* way. That
operation will block until there's a reader for the FIFO, and such
a reader will appear when s6-svscan's logger is up, which means that
s6-svscan is up and running and has started its own logging service.
At this point, the background process can unblock, and run what I
call init-stage2, which can mount filesystems, populate the scan
directory and call s6-svscanctl -a to start services, etc.
c) needs a way to *not* block on the FIFO while there is no reader,
and that's why redirfd is handy here.
Note that this scheme allows exactly every service on the system to
be supervised. Even udev. Even s6-svscan's own logger. I believe this
is the cleanest way to use a supervision infrastructure.
There is no theoretical objection to using that scheme with runit or
daemontools too. There simply are two practical roadbumps:
* The FIFO trick. This can be solved by using execline's redirfd even
in a daemontools/runit installation, or by adding a few lines of
special code to daemontools/runit.
* The fact that runsvdir/svscan can wait for up to 5 seconds before
launching a requested service: there is no way to trigger a scan like
there is with s6. This makes it hard to populate a scan directory
sequentially, because the waiting times (before runsvdir picks up the
new service directory and starts the service) will add up, and the
boot process will be very slow.
But as a proof of concept, it could be done.
--
Laurent
Received on Tue Jan 06 2015 - 03:28:59 UTC