RE: B/LFS-s6 Project

From: James Powell <>
Date: Wed, 25 Jun 2014 21:21:35 +0000

As it stands our base system is going to based off of the current developer version (06-15-2014 with eudev-1.8 from 06-23-2014 rather than 1.7) of the Linux From Scratch distribution. The bootstrap system is under construction, so progress is moving ahead steadily.

At current our plans are as such:

1. Write a stage-1 init script in standard Linux Bash shell scripting. Because Bash is the stereotypical universal Linux shell on most distributions, we felt that it's usage in the scripting process would aid and ease s6 into the system faster and cleaner. However, we are not above utilizing scripting using execline if necessary as a learning tool, but our goal is to use standard Bash.

2. As far as service scripts are concerned, we may use either execline or bash scripting depending on which moved things along faster.

> Date: Tue, 24 Jun 2014 22:51:49 +0100
> From:
> To:
> Subject: Re: B/LFS-s6 Project
> > 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 Wed Jun 25 2014 - 21:21:35 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC