Summary of s6-66 exploration
Introduction
There was a long topic
in which I took a first look at the 66 Service Manager for the S6 init system.
I was fortunate to obtain assistance from
- @ProwlerGR – the author of the init diversity spins
- @Obarun – the author of the
66service manager and also creator of the Obarun distro which is Arch Linux with S6-66.
It is time for a summary.
This is a stage summary, not a tutorial.
We are fortunate to have been able to see this important development in its early stages, and we appreciate the assistance of @ProwlerGR and @Obarun.
Please make any corrections or modifications. I have learnt something, but I am by no means an expert.
Brief history of init systems
Some of the things a running Linux system does are outside of the kernel. These are either
- packages run in ‘user space’ , or
- services ( also called daemon processes)
Traditionally , after the kernel starts, it starts one process( calledinit) ,
which consults some config files, which tell it what other daemon processses
to start.
Traditional daemon processes are slightly different to user-launched processes in that they are orphaned ( ie not owned by a shell). That mens they dont die, if you exit the shell… traditional daemons run forever… at least in theory.
In practice, they die unexpectedly, and have to be manually restarted.
That is the reality in a traditional init system like RC, sysVinit, or OpenRC.
At some point, it was decided that daemons need to be managed. That means that instead of fixing bugs in the daemon, we automatically restart it when it fails.
A whole spectrum of new init systems emerged – Upstart, Systemd, Runit, S6, Dinit, Shepherd.
Systemd has dominated in Linux, but not in BSD. It is the default in Debian, OpenSUSE, RHEL, and Arch.
Systemd has been criticized for violating Unix philosophy. It is large and a big learning curve. Systemd is like traditional init systems in that there is only one process running for each daemon started. A single process manages all running daemons.
Systemd is unlike traditional init systems in that it has parallel startup, users as well as root can manage services, and it has ways of managing multiple services as a group. (Correct me here if needed… I do not know systemd well).
The Runit and S6 init systems are different. They are both based on a package called ‘daemontools’, which manages daemons by having a separate supervise process ( in addition to the daemon process itself) running for each daemon. There may also be a logging process for each daemon, and a supervise process for the logging process… In this system , daemons are not orphaned, they belong to the supervise process.
Runit has supervision and parallel startup, , but not tools for service management( ie starting and stopping services) – you do it by hand, and no management of dependencies…
S6 has supervision plus service management, and it manages dependencies… The original service manager ( called S6-rc) has been available for some time, but has a few non-friendly concepts (such as compiling the database and writing execline scripts ) which make it clumsy to use. S6-rc has bundles which allow serveics to be grouped and managed as a unit.
There is a new service manager for S6 ( called S6-66) which has an elegant design and is much more user friendly. S6-66 avoids compiling a database, and it has a ‘frontend’ file instead of an execline script. 66 has ‘trees’, which are like bundles, and it allows users to manage services, as well as root.
This topic is about s6-66, but the background is important. In S6-66 we are looking at a facility with a substantially different philosophy to either systemd or traditional init systems.
My impressions after using s6-66 for several weeks
In S6-66 we are looking at an init facility based on couple of seriously
innovative academic initiatives.
-
the
daemontoolspackage is a set of tools for daemon management
developed by the brilliant mathematician D J Bernstein, who has a number of papers on maths and computer algorithms. -
the S6 part of s6-66 is a really thorough implementation of
daemontools
fromskarnet.org. It is this initiative which adds parallel startup
and ****** dependency management ****** my error… it is66which adds dependency management… S6 supplies the daemontools implementation ( like Runit only more sophisticated) -
the
66part of s6-66 ( ie the service manager) is a design revolution
for the user interface to init systems. There is only one command ( called66) and there are subcommands. So it is designed likegitorapt… the modern way to build a CLI command. There are no scripts … there is a user modifiable config file called a 'frontend` that sets up everything for a service… all in one place.
So we are dealing with something that is the combined product of a number of seriously innovative people. What you tend to get in such cases is something with a theory ( a philosophy if you like) behind it. In contrast software from large cooporate efforts tends to be a collection of poorly integrated tools with
inconsistent approaches
.
Concepts used by 66
It is important to understand the underlying ideas.
-
66 – the name of the command that performs all Service Management actions ( except setting up a frontend file for a service).
66has subcommands ( likegit) and there is a help menu displayed by66 -hor66 <subcommand> -h -
service – a process that runs automatically in background. The process is often called a daemon. Daemons in S6 ( and runit) are not orphaned the way they are in other init systems … they are owned by a supervise process which persists.
-
frontend – a user-written file providing information ( for setting up a service) from which 66 constructs and stores an execline script and other details. For root frontends are in ‘/etc/66/service’ and for normal users frontends can be in '~/.66/service
or '/etc/66/service/user'. Frontends need to be accessed once with the66 parsecommand, and if they are altered need to be re-accessed with the66 reconfigure` command. -
service type – classic, oneshot or module. Describes the way a service is used
- classic service – a typical persistent daemon ( called longrun in s6-rc)
- oneshot service – a service that performs one action then dies. ( for example a mount)
- module service – a service ( or a bundle of services) whose actions can be modified at runtime by setting the environment. The names of services of type module end in ‘@’
-
instantiated – refers to the mechanism by which service actions can me modified at runtime. Any type of service can be instantiated. A module service is always instantiated. Instantiated services have an ‘@’ in their name ( eg tty@) and use an ‘@I’ in the frontend as a placemarker for a value substituted at runtime.
-
tree – a collection of services ( like a bundle in s6-rc) which
can be managed together by one66 tree ...command.
There is aglobaltree which is the default and is present at install time.
The ‘global’ tree is always enabled - ie it starts automatically at boot time.
New services default to the global tree unless another tree is specified.
There is a ‘boot’ tree which contains various services needed when the system boots.
There is a tree called ‘session’ which containes modules which setup an environment in which a user can manage services.
Other user-defined trees can be created. A service can only belong to one tree.
Any type of service can belong to a tree, even a module service.
A tree can not be nested within another tree. -
enable/disable – something that is ‘enabled’ starts automatically at boot
time. A single service can be enabled. A tree can be enabled. -
stop/start – start means launch a service immediately. A tree can be started immediately. When a tree started, only the services within it that are enabled
will start. -
scandir – a directory ( /run/66/scandir/…) containing, for each user, the compiled version of the frontend for each running service, plus a number of status files. For root it is /run/66/scandir/0/…, for the first user it is /run/66/scandir/1000/… There is a special admin command to manage scandirs.
The root scandir is automatically created. A user scandir must be initialised with the66 scandir ...command, before any user services can be started. -
boot@system – a special module that creates a tree called ‘boot’ that containes all the services needed for the system to boot properly.
-
boot-user@username – a special module that creates a tree called ‘session’ that contains modules which setup an environment in which a user can manage user owned services.
Setting up a frontend file
Each service requires a ‘frontend’ file. This is how services are configured.
Root frontend files are in /etc/66/service. User frontend files are in ~/.66/service.
When the system is installed, there will be some root frontend files present in /etc/66/service. These are useful as examples.
New services will require a ‘frontend file’ . We give a simple example of installing and starting a new service ‘vsftpd’.
apt install vsftpd
this makes sure the vsftpd binary is present.
We need to make a file called vsftpd in /etc/66/service containing
[main]
@type=classic
@description="vsftpd daemon"
@version=0.0.1
@user=(root)
[start]
@execute=(
/usr/sbin/vsftpd
)
‘classic’ means it is a traditional daemon, ie not a ‘oneshot’ or a ‘module’
this service can be started by root only
the binary is at /usr/sbin/vsftpd
This is a new frontend. It has to be parsed once
66 parse vsftpd`
Then it can be started
66 start vsftpd
***** not quite right… 66 start ... will do a 66 parse ... if it has not been done ******
If there is a mistake in the frontend, and you need to edit it, you then need to do
66 reconfigure vsftpd
which will re-parse it and re-start it.
That is all there is to starting a simple daemon.
There are more complicated things, such as setting environment variables, and defining dependencies between services.
Some examples of tasks and how to do it with 66
Everyone needs a recipe book. This is not comprehensive … just gives a taste of how easy 66 is to use.
Operating as root user
Start a service immediately
66 start <servicename>
Enable a service, so it will start at boot time.
66 enable <servicename>
Look at the status of a service
66 status <servicename>
Look at the available trees
66 tree status
To make a new tree you simply start a service specifying that tree
66 -t <newtree> start <servicename>
That will also add a service to an existing tree
To start a tree
****** 66 start <treename> ******** my error
66 tree start <treename>
ie, the same as starting a single service. All services within that tree will start if they have been enabled. You can use this to selectively start part of a tree by disabling unwanted services. If you want the tree to start automatically at boot
you have to enable the tree
***** 66 enable <treename> ****!** My error
66 tree enable <treename>
Operating as non-root user
Before any normal user can use ‘66’ , root has to setup a module which establishes
the user environment. For example
66 parse boot-user@nevj
66 configure -e nano boot-user@nevj
edit the config ( eg set window manager)
66 reconfigure boot-user@nevj
always needed after a config is changed
there will then be a new tree called ‘session’
root@antix-init-diversity:~# 66 tree status
Name : session
Current : no
Enabled : no
Allowed : root
Groups : admin
Depends : None
Required by : None
Contents : scandir@nevj:setenv@nevj scandir@nevj:svscan@nevj
scandir@nevj:svscan@nevj-log scandir@nevj
boot-user@nevj:mount-run@nevj boot-user@nevj
and it contains various module services which setup user ‘nevj’s’ environment
Now, each time ytyou boot you need root to do
66 start boot-user@nevj
and that sets up nevj’s environment.
Now user ‘nevj’ can use all the same 66 commands as in above examples for root.
User ‘nevj’ has his own global tree, which is separate from root’s global tree, and user ‘nevj’ can not see or manipulate the system trees.
Otherwise everything is the same as operating as root.
66 documentation
There is adequate documentation on the internet. 66 , as implemented in the init-diversity-spins, does not have man pages. However the source does have man pages, and they are present in Obarun Linux.
66 does have a help option
66 -h <subcommand>
will give a help page for the subcommand.
The '66’command:
https://web.obarun.org/software/66/latest/66.html
Frontend files:
https://web.obarun.org/software/66/latest/66-frontend.html
Trees:
https://web.obarun.org/software/66/latest/66-tree.html
Scandir:
https://web.obarun.org/software/66/latest/66-scandir.html
The toplevel page:
https://web.obarun.org/software/66/latest/index.html
Internals:
https://web.obarun.org/software/66/latest/66-deeper.html
S6:
Beware of old versions… if you see anything like 66-start ... that is old
deprecated stuff.
Thank you again to all involved.
