From c2740b983f6bb4baf0d5a1772fa3682cc66aa5f9 Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Sun, 18 Jan 2026 02:50:51 +0000 Subject: Add s6 live install --init ; finish and fix documentation --- doc/overview.html | 316 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 316 insertions(+) create mode 100644 doc/overview.html (limited to 'doc/overview.html') diff --git a/doc/overview.html b/doc/overview.html new file mode 100644 index 0000000..f4d16f7 --- /dev/null +++ b/doc/overview.html @@ -0,0 +1,316 @@ + + + + + + s6-frontend: overview + + + + + + +

+s6-frontend
+Software
+skarnet.org +

+ +

s6-frontend: an overview

+ +

Contents of the s6-frontend package

+ +

+ The s6-frontend package does not itself contain much. The only binary +that users will interact with directly is the +s6 binary, which is a wrapper around the +s6-frontend binary (which users +should not have to call directly), which is itself a wrapper around +various commands of the s6 ecosystem that users also need to have +installed in order for s6-frontend to work. That means: +

+ + + +

Installing s6-frontend

+ +

+ In addition to the s6-frontend package and its dependencies, in order to +make use of the s6 command, you will need +service definitions: a set of directories, in a format understandable +by s6-rc-compile, +describing various services that can run on a machine — long-running +daemons, one-shot scripts, and "bundles" aliasing to a group of these services. +

+ +

+ If you are running s6-frontend from a distribution, the packages that provide +these services should already have them defined, and the service definition +directories should already made available in some pre-configured +stores. Your +distribution should also have pre-installed everything you need in order +for yo to be able to use the s6 command to +control the system. But if you are installing s6-frontend manually, or are +the person building the distribution, here is what you need to do: +

+ + + + +

Concepts

+ +

+ s6-frontend does not come with any innovating concepts — it's just a series +of user-friendly wrappers around various commands in the s6 ecosystem, hiding +the details of various options and installation directories. For instance: +

+ + + +

+ The most innovating change comes from the +repo commands, in the +version of s6-rc that is released at the +same time as the first release of s6-frontend. The goals of the repo commands, which +are wrapped by the s6 repository and +s6 set commands, are: +

+ + + +

Comparison with OpenRC

+ +

+ One of the design goals of s6-frontend is to provide a user interface to service +management that is comparable to the one provided by OpenRC. +

+ +

+ A fundamental difference between s6-frontend and OpenRC is that OpenRC always +works on live services, the ones that are currently running on the +user's machine. It only has one live database, comprising several +"runlevels" (sets of services meant to be run together), and manages its +dependency tree dynamically. +

+ +

+ s6-frontend, on the other hand (and more accurately, this is the domain of +the s6-rc service manager and its +repo commands), +separates the notion of live database and of working set +entirely. The working set is worked on offline, without +impacting the current machine state. You can start and stop +live services, but you can only enable or disable +— or mask — services on the working set. Enabling a +service means that next time you boot on the service database you are +working on, that service will be automatically started.
+ Once you have worked on a set of services, you can replace the live +database with it; the old live database disappears entirely, and your +working set (well, a copy of it) is now live. +

+ +

+ A corollary of that is that s6-frontend does not have runlevels. It does +not need them. The default bundle specifies what services should +be started at boot; other bundles (in the sense of s6-rc) can be defined +in the stores, and the user can start and stop them at will, as well as +start and stop individual services, dependencies notwithstanding. By +default, all the services are accessible in the live database, but the +user can choose to exclude certain services by masking them in +a working set and then installing that set. +

+ +

+ These differences being given, s6-frontend should be very comparable to +OpenRC in its everyday usage. Here is a table showing some correspondences; +it is not meant to be exhaustive, but to show a representative enough sample +of the kind of commands that can be worked with. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OpenRC command s6-frontend equivalent Notes
rc-service foobar start s6 live start foobar Starts a service in the live database.
rc-service foobar status s6 live status foobar or s6 process status foobar s6 process status foobar only works if foobar is a longrun, +in which case it will give detailed information on its supervised instance.
rc-status default s6 live status or s6 set status s6 live status shows the status of the current live database, +s6 set status the status of the offline working set.
rc-update add foobar s6 set enable foobar See below.
rc-update del foobar s6 set disable foobar See below.
rc-update show s6 set status Shows the enabled, disabled and masked services, but to make the +changes effective, the user needs to run s6 set commit then +s6 live install.
openrc sysinit && openrc boot && openrc default s6 system boot The existence of the sysinit and boot runlevels are a +historical wart that OpenRC still has to deal with; s6-frontend does not.
reboot reboot or s6 system reboot Just like OpenRC's reboot command will only work if the system +is using openrc-init, s6 system reboot command will only work +if the system is using s6-linux-init.
+ + + -- cgit v1.3.1