> The same will go for s6. Right now our first task is building a clean
> room LFS to deploy s6 into. The only imported tools for s6 we will be
> utilizing are the execline and skalibs packages. The rest will be
> native GNU/Linux.
In that case, GNU coreutils will have to be part of the base system,
because the /sbin/init script will call utilities such as cp or env.
You will also have to decide what language to write /sbin/init in.
If you use /bin/sh, then your base shell (bash?) will also be part of
the base system.
I wrote my stage 1 init script using only execline and s6-linux-utils,
which I wrote to avoid a dependency to coreutils or busybox until I
have s6-svscan running, to have the strict bare minimum on a tiny root
filesystem. But it was mostly a theoretical exercise since people will
usually need coreutils anyway, and I've since found that the size of
your root filesystem doesn't matter as long as it's read-only.
> One hope we are wanting to test is if Runit service scripts can
> actually be reused in s6. This would promote a high level of
> compatibility with our current work, leaving only the native s6
> logging tools to supplement the Runit logging tool, not to mention
> save a lot of research time.
Most runit service scripts should work as is with s6.
What runit provides that s6 does not support:
- The sv command supports the /etc/init.d LSB script interface.
The s6-svc command does not. However, it is trivial to write a script
that performs that functionality if desired.
- the human-readable supervise/stat and supervise/pid files
- the control/ customization subdirectory
- the check script
What s6 provides that runit does not support:
- the event/ subdirectory and no-polling checks of the service
state via the s6-svwait command
- the nosetsid file
Service directories that do not make use of those functionalities
will be portable from one system to another.
> However, as far as the one-shots of stage-1, while we recycled
> sysvinit scripts for Runit, we would like to have s6's stage-1s
> script contain all the one-shot init information if possible using
> all the core functions of the base sysvinit scripts of LFS, while
> invoking one-shots using checked triggers as previously described,
> the same with stage-3s shutdown sequence also. We want s6 to be more
> native to itself script-wise.
One decision you'll have to make early: do you wish to implement
service dependencies ? If you do, it's a matter of scripting around
s6-svwait, but you need to take it into account in the init scripts,
and possibly in the run files as well - which would break runit
compatibility.
Note that even with s6-svwait, there are race conditions when you
are waiting for a service to come up. s6-svwait can tell when
s6-supervise has successfully spawned its run script, but it cannot
tell when the run script has actually become an operational service.
To avoid race conditions, the service itself has to notify the
outside world when it is ready.
> I should have the base system up and running within a week in my
> spare time, so I'll start from the example implementation provided
> and work my way out from there.
Good luck, Jim. ;)
Feel free to ask for details if there's something you don't
understand in the example implementation and it's not explained (or
not clearly enough) in doc/s6-svscan-1.html - there are definitely
a few tricky points, and at this fundamental level it's important to
get them right.
--
Laurent
Received on Tue Jun 24 2014 - 21:51:49 UTC