Obarun and S6
The suite S6 - Skarnet.org’s Small & Secure Supervision Software Suite includes an init, one of several projects that rebelled against SystemD by trying to prove there were better and/or simpler ways to do the same thing.
Despite the official implementation of S6 began to be on Alpine Linux, for some reason the author now collaborates with Adélie Linux, which I’ve already tried.
However, the most mature implementation of S6-init seems to be on Obarun, an Arch-based distro and, as far as I know, without any input from the author of S6, despite all of them being French. I say this because S6 still hasn’t specified a mechanism to organize the dependencies between services (and being a “UNIX Way”-zealot, it might never do so), which means someone else has to do it; and Obarun’s contribution is a set of scripts called 66
Therefore, to try S6 I had to install Obarun; being Arch-based, I feared the worst, but compared to Adélie it was actually pretty simple to install.
Installation Notes
- The PT-UTF8 locale has bad character rendering on the text console (wrong settings on
grub.cfg?)
I reinstalled with the en_GB-UTF8 locale and it worked properly. - If you install on Minimal mode, VirtualBox’s NAT provides the DHCP options and the nameserver address (DHCP option 5) is written to
/etc/resolv.conf; on a NATnetwork it doesn’t,/etc/resolv.confhas to be edited by hand. VirtualBox bug? NATnetwork is known for being buggy, maybe one of those is failing to send DHCP options - but I didn’t deploy a packet sniffer to check…
S6/66 (v.6.3+)
66 is, as i said, a management layer over the S6 suite, which is based on the creation of a set of trees by the administrator; these trees are something in-between the numerical/alphabetical ordering of SysV-init and the dynamically-updated graph of SystemD.
Example: installing SSHD
The sshd service is installed with
|
|
66 stage 1: service script
The service script to control the openssh service isn’t installed automatically; it must be created, or obtained from the scripts that exist in the observice repository. All the service scripts that exist in this repo can be listed with:
|
|
To install the necessary service script,
|
|
To tell the system the service was added,
|
|
Now we can look at the contents of the service script with:
|
|
Name : sshd
Version : 0.2.1
In tree :
Status :
Type : classic
Description : ssh daemon
Source : /usr/lib/66/service/sshd
Live : /run/66/scandir/0/sshd
Dependencies : sshd-log
External dependencies : None
Optional dependencies : None
Start script :
foreground { exec ssh-keygen -A }
execl-cmdline -s { /usr/sbin/sshd -f ${conf_file} ${cmd_args} }
Stop script : None
Environment source : /etc/66/conf/sshd/0.2.1
Environment file :
environment variables from: /etc/66/conf/sshd/0.2.1/.sshd
conf_file=!/etc/ssh/sshd_config
cmd_args=!-D
Log name : sshd-log
Log destination : /var/log/66/sshd
Log file : None
66 stage 2: configure dependencies
However, services have to be added to a tree before starting; the tree codifies the services' dependencies.
To see and manipulate the trees, the 66-intree command is used (from 66 version 0.6x onwards)
I find the -g switch very useful, since it shows the dependency structure of the services that are configured in the trees.
|
|
Name : boot
Initialized : yes
Enabled : no
Starts after : None
Current : no
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(144,Enabled,classic) tty-earlier@tty12
├─(up,Enabled,oneshot) system-hostname
├─(up,Enabled,oneshot) mount-run
├─(up,Enabled,oneshot) populate-run
├─(up,Enabled,oneshot) mount-tmp
├─(up,Enabled,oneshot) populate-tmp
├─(up,Enabled,oneshot) mount-proc
├─(up,Enabled,oneshot) mount-sys
├─(up,Enabled,oneshot) populate-sys
├─(up,Enabled,oneshot) mount-dev
├─(up,Enabled,oneshot) mount-pts
├─(up,Enabled,oneshot) mount-shm
├─(up,Enabled,oneshot) populate-dev
├─(up,Enabled,oneshot) mount-cgroups
├─(up,Enabled,bundle) 00
├─(up,Enabled,bundle) all-Mount
├─(up,Enabled,oneshot) system-hwclock
├─(up,Enabled,oneshot) modules-kernel
├─(up,Enabled,oneshot) system-random
├─(up,Enabled,oneshot) modules-system
├─(up,Enabled,oneshot) system-sysctl
├─(184,Enabled,longrun) udevd-log
├─(359,Enabled,longrun) udevd
├─(up,Enabled,oneshot) udevadm
├─(up,Enabled,oneshot) system-fontnkey
├─(up,Enabled,oneshot) system-fsck
├─(up,Enabled,oneshot) mount-fstab
├─(up,Enabled,bundle) all-System
├─(up,Enabled,oneshot) mount-rw
├─(up,Enabled,oneshot) mount-netfs
├─(up,Enabled,oneshot) local-loop
├─(up,Enabled,oneshot) local-sethostname
├─(up,Enabled,oneshot) local-time
├─(up,Enabled,oneshot) local-authfiles
├─(up,Enabled,oneshot) local-tmpfiles
├─(up,Enabled,oneshot) local-dmesg
├─(up,Enabled,bundle) all-Local
├─(up,Enabled,oneshot) all-Runtime
├─(up,Enabled,bundle) All
├─(580,Enabled,longrun) tty-rc@tty1
├─(579,Enabled,longrun) tty-rc@tty2
└─(up,Enabled,module) boot@system
Name : root
Initialized : yes
Enabled : yes
Starts after : None
Current : yes
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(567,Enabled,classic) dhcpcd-log
└─(566,Enabled,classic) dhcpcd
To activate the service and start it at the correct place of the startup process, we create a new tree called net (that will run services that depend on the network being configured) after the root tree (where the dhcpcd service which sets the network up currently resides):
|
|
66-tree: info: Created successfully tree: net 66-tree: info: Enabled successfully tree: net 66-tree: info: Ordered successfully tree: net starts after tree: root
After creating the new tree, add the sshd service to that tree:
|
|
66-enable: info: Enabled successfully: sshd
And finally start all services on that tree:
|
|
66-all: info: Initialized successfully: sshd-log 66-all: info: Initialized successfully: sshd 66-all: info: Initialization: no atomic services into tree: net 66-all: info: sshd-log: started successfully 66-all: info: sshd: started successfully
Now we can connect to Obarun by SSH.
We can see the changes that were made by repeating the command 66-intree -g
Name : boot
Initialized : yes
Enabled : no
Starts after : None
Current : no
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(144,Enabled,classic) tty-earlier@tty12
├─(up,Enabled,oneshot) system-hostname
├─(up,Enabled,oneshot) mount-run
├─(up,Enabled,oneshot) populate-run
├─(up,Enabled,oneshot) mount-tmp
├─(up,Enabled,oneshot) populate-tmp
├─(up,Enabled,oneshot) mount-proc
├─(up,Enabled,oneshot) mount-sys
├─(up,Enabled,oneshot) populate-sys
├─(up,Enabled,oneshot) mount-dev
├─(up,Enabled,oneshot) mount-pts
├─(up,Enabled,oneshot) mount-shm
├─(up,Enabled,oneshot) populate-dev
├─(up,Enabled,oneshot) mount-cgroups
├─(up,Enabled,bundle) 00
├─(up,Enabled,bundle) all-Mount
├─(up,Enabled,oneshot) system-hwclock
├─(up,Enabled,oneshot) modules-kernel
├─(up,Enabled,oneshot) system-random
├─(up,Enabled,oneshot) modules-system
├─(up,Enabled,oneshot) system-sysctl
├─(184,Enabled,longrun) udevd-log
├─(359,Enabled,longrun) udevd
├─(up,Enabled,oneshot) udevadm
├─(up,Enabled,oneshot) system-fontnkey
├─(up,Enabled,oneshot) system-fsck
├─(up,Enabled,oneshot) mount-fstab
├─(up,Enabled,bundle) all-System
├─(up,Enabled,oneshot) mount-rw
├─(up,Enabled,oneshot) mount-netfs
├─(up,Enabled,oneshot) local-loop
├─(up,Enabled,oneshot) local-sethostname
├─(up,Enabled,oneshot) local-time
├─(up,Enabled,oneshot) local-authfiles
├─(up,Enabled,oneshot) local-tmpfiles
├─(up,Enabled,oneshot) local-dmesg
├─(up,Enabled,bundle) all-Local
├─(up,Enabled,oneshot) all-Runtime
├─(up,Enabled,bundle) All
├─(580,Enabled,longrun) tty-rc@tty1
├─(579,Enabled,longrun) tty-rc@tty2
└─(up,Enabled,module) boot@system
Name : root
Initialized : yes
Enabled : yes
Starts after : None
Current : yes
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(565,Enabled,classic) sshd-log
├─(567,Enabled,classic) dhcpcd-log
├─(566,Enabled,classic) dhcpcd
└─(564,Enabled,classic) sshd
Name : net
Initialized : yes
Enabled : yes
Starts after : root
Current : no
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(565,Enabled,classic) sshd-log
└─(564,Enabled,classic) sshd
Final thoughts
Yes, 66’s trees allow us to manage the dependencies of services in a slightly more intuitive way than the classic numbered scripts of SysV-init, but they are very far from the ease of use of SystemD’s service units, which are declarative.
In addition, the installation and configuration of SystemD’s service units is automated most of the time by the package managers of SystemD-supporting distros, and by being declarative, all that’s needed is to create the service unit and then SystemD will take charge of extracting the dependencies and parallelism in the configured services. Although 66 supports the parallel startup of services through the use of trees, it still falls to the administrator to define exactly the starting order of each service.
For those wanting more control over the boot process than what’s offered by SystemD, it’s great, or at least less work-intensive than SysV-init. 66’s scripts do help, but not much.
Of course what S6, OpenRC, Runit, etc, are missing, are the thousands of hours of programming that were invested on SystemD and quantity in this case has a quality in itself. In comparison, all these inits are a cake which is missing the yeast to rise.
If you are interested in contributing to this project, they need you.