From OpenRC to s6: Any tips?

[alecStewart1]

Hello friends!

To better understand init systems, I thought I'd try switching from OpenRC to s6.

The documentation is a bit to go through, as so is the wiki page, but this wiki by user Capezotte does a good job of explaining things with the examples.

I've also looked at the s6 scripts Artix uses for both general system initialization/cleanup and for some other services

Basically, for anyone wondering:

Your init scripts are in a "database." This could be a /etc/s6/db, /etc/s6/src, whatever. s6 has to "compile" those scripts into another folder like /etc/s6/[some unique name]. That would be what /etc/init.d is for OpenRC.

Each service has it's own folder, which must contain at least a file called "type" that should have one of the following and a terminating newline:

• oneshot # something that runs once and that's it, i.e. mounting the filesystem
  longrun # something that runs in the background, i.e. sshd
  bundle # a combination of the previous two or itself, each line listing one name of the oneshot longrun service or another bundle, i.e. a series of explicit mount commands that are services

A "bundle" is a grouped series of services such as everything you want to run on boot. A bundle folder must contain the "type" file with the word "bundle" and a newline and a folder named "contents.d" whose contents are (usually) empty files that are named after the services you want to run in that bundle

Services can depend on one another, so say for binfmt you want to make sure the procfs is mounted first in the binfmt folder you have a subfolder named "dependencies.d" with a (usually) empty file named "mount-procfs" or whatever. (See the Artix scripts for examples)

To bring a service up, there needs to be a file named "up" that's a script (it needs to have a shebang) that runs the service. It could be a shell script, execline scripts, or even a Python, Perl, or Ruby script.
On the flip side, to do something specific to bring a service down there needs to be file named "down" that is also a script.

I don't know why I went into a very basic and brief description of s6 but there you go.

Looking at the Artix s6 scripts and services, is there anything missing from there that would been needed for Gentoo? I will say the OpenRC net.* init scripts are uh, quite large, so I don't know if I really need to implement all of that. The Artix scripts just have

Code: Select all

#!/bin/execlineb -P
exec ip link set up dev lo

and that's it. It looks like the OpenRC net.* scripts look at the kernel modules and checks if a given interface exists so we don't do:

Code: Select all

ip link set up dev foobarbaz # <- a nonexistent interface

But that seems to be generic, given these scripts are used on many machines where we don't know if a given interface actually exists or not.

Other than that for things like mounting the filesystems I can just use `mount -a` since my /etc/fstab is really simple:

Code: Select all

UUID=LONG-UUID						/boot		  vfat		defaults,noatime	0 2
UUID=LONGER-UUID		none		  swap		sw		  	0 0
UUID=LONGER-UUID		/		  btrfs		compress=zstd:10,clear_cache,noatime		  	0 1
tmpfs							/var/tmp/portage  tmpfs		size=16G,uid=portage,gid=portage,mode=775,nosuid,noatime,nodev	0 0

I don't see anything in the Artix scripts for mtab, so that's something of note.

The only other thing would be that in some of the OpenRC scripts' "depend" function there's "after", "before", etc and I'm not entirely sure if that's something needed or used in s6.

[GDH-gentoo]

Looking at the Artix s6 scripts and services, is there anything missing from there that would been needed for Gentoo?

That's hard to say without reviewing the whole service definition set.

I have a Gentoo virtual machine on VirtualBox (i.e. not real hardware yet) with an s6-based init system. I converted OpenRC service scripts to s6-rc service definitions one by one, after taking some time to study them, because I wanted the s6-based init system to set things up as closely as possible to the way that OpenRC on Gentoo sets them up. But that was greatly simplified because it wasn't my goal (unlike Artix's service set) to make them generic and suitable for every scenario, they just had to boot that particular VM. Also, the VM itself doesn't have a lot of packages, although it does boot to a display manager (SDDM), and start an X11 window manager (Openbox) once I log in.

A generic set would require much more work. And probably, until s6-rc-1.0.0.0 comes out, some kind of user-friendlier front-end (as a separate, ditribution-specific package) for creating the service set submitted to s6-rc-compile. I'm thinking of something e.g. Ncurses-based, like the kernel's make menuconfig.

Anyway, here's what the active s6-rc services look like:

Code: Select all

# s6-rc -a list | sort
agetty@tty1
agetty@tty2
agetty@tty3
agetty@tty4
agetty@tty5
create-wtmp
dbus-daemon
dbus-logger
devfs
fsck
hostname
hwclock
keymaps
klogd-logger
klogd-ucspilogd
kmod-static-nodes
localmount
loopback
lvm
lvmetad
mount@-dev-mqueue
mount@-dev-pts
mount@-dev-shm
mount@-sys
openrc-cgroups
proc
root
run-lock
s6rc-fdholder
s6rc-oneshot-runner
sddm-daemon
socklog-daemon
socklog-logger
swap
sysctl
systemd-udev
truncate-utmp
udev-trigger
urandom
VBoxService-daemon
VBoxService-logger
wipe-tmp
X11-tmp

There should be one more oneshot for running systemd-tmpfiles, but on this particular VM I found that all relevant programs create all files and directories in /run themselves if /usr/lib/tmpfiles.d is not processed.

And here's what the running processes look like (supervision tree and processes not directly supervised by s6):

Code: Select all

  PID EUSER    EGROUP   TTY      COMMAND
    1 root     root     ?        s6-svscan -X3 -- /run/service
   68 root     root     ?        s6-supervise s6-linux-init-runleveld
   73 root     root     ?         \_ s6-ipcserverd -1 -c 1 -- s6-sudod -dt30000 /etc/s6-linux-init/current/scripts/runlevel
   69 root     root     ?        s6-supervise s6-linux-init-early-getty
   72 root     root     tty6      \_ agetty --nohostname -f issue 38400 tty6 linux
   70 root     root     ?        s6-supervise s6-linux-init-shutdownd
   75 root     root     ?         \_ s6-linux-init-shutdownd -c /etc/s6-linux-init/current -g 3000
   71 root     root     ?        s6-supervise s6-svscan-log
   74 daemon   daemon   ?         \_ s6-log -bpd3 -- 1 t /run/uncaught-logs
   90 root     root     ?        s6-supervise agetty@tty3
  527 root     root     tty3      \_ agetty 38400 tty3 linux
   91 root     root     ?        s6-supervise s6rc-oneshot-runner
  118 root     root     ?         \_ s6-ipcserverd -1 -- ... -- /lib/skarnet/s6-rc-oneshot-run -l ../.. --
   92 root     root     ?        s6-supervise agetty@tty4
  511 root     root     tty4      \_ agetty 38400 tty4 linux
   93 root     root     ?        s6-supervise systemd-udev
  230 root     root     ?         \_ /lib/systemd/systemd-udevd
   95 root     root     ?        s6-supervise lvmetad
  140 root     root     ?         \_ lvmetad -f
   96 root     root     ?        s6-supervise VBoxService-daemon
  496 root     root     ?         \_ VBoxService -f
   97 root     root     ?        s6-supervise VBoxService-logger
  410 daemon   daemon   ?         \_ s6-log -d3 n1 s10240 t /var/log/s6/VBoxService
   99 root     root     ?        s6-supervise klogd-ucspilogd
  433 root     root     ?         \_ ucspilogd
  100 root     root     ?        s6-supervise socklog-daemon
  447 daemon   daemon   ?         \_ socklog
  101 root     root     ?        s6-supervise s6rc-fdholder
  146 root     root     ?         \_ s6-fdholderd -1 -i data/rules
  102 root     root     ?        s6-supervise dbus-logger
  420 daemon   daemon   ?         \_ s6-log -d3 n1 s10240 t /var/log/s6/dbus
  103 root     root     ?        s6-supervise agetty@tty5
  509 root     root     tty5      \_ agetty 38400 tty5 linux
  104 root     root     ?        s6-supervise klogd-logger
  421 daemon   daemon   ?         \_ s6-log -d3 n1 s10240 t /var/log/s6/klogd
  105 root     root     ?        s6-supervise socklog-logger
  418 daemon   daemon   ?         \_ s6-log -d3 -- n1 s10240 - +^auth(priv)?\. /var/log/syslog/auth - ...
  106 root     root     ?        s6-supervise agetty@tty2
  532 root     root     tty2      \_ agetty 38400 tty2 linux
  107 root     root     ?        s6-supervise dbus-daemon
  437 message+ message+ ?         \_ dbus-daemon --system --nofork --nopidfile
  108 root     root     ?        s6-supervise sddm-daemon
  495 root     root     ?         \_ sddm
  585 root     root     tty7          \_ /usr/bin/X -nolisten tcp -auth ... -background none -noreset -displayfd 17 -seat seat0 vt7
  599 root     root     ?             \_ /usr/libexec/sddm-helper --socket ... --start /usr/bin/openbox-session ...
  600 user     user     ?                 \_ /usr/bin/openbox --startup /usr/libexec/openbox-autostart OPENBOX
  109 root     root     ?        s6-supervise agetty@tty1
  528 root     root     tty1      \_ agetty --noclear 38400 tty1 linux
  487 root     root     ?        elogind-daemon
  609 user     user     ?        /usr/bin/VBoxClient --clipboard
  610 user     user     ?         \_ /usr/bin/VBoxClient --clipboard
  621 user     user     ?        /usr/bin/VBoxClient --seamless
  622 user     user     ?         \_ /usr/bin/VBoxClient --seamless
  628 user     user     ?        /usr/bin/VBoxClient --draganddrop
  630 user     user     ?         \_ /usr/bin/VBoxClient --draganddrop
  633 user     user     ?        /usr/bin/VBoxClient --vmsvga
  634 user     user     ?         \_ /usr/bin/VBoxClient --vmsvga
  647 user     user     ?        /usr/bin/dbus-launch --exit-with-session /usr/bin/openbox-session
  648 user     user     ?        /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
  671 user     user     ?        urxvtd -q -o

I will say the OpenRC net.* init scripts are uh, quite large, so I don't know if I really need to implement all of that.

That's because they are generic, and a lot of shell code in net-misc/netifrc is devoted to parsing /etc/conf.d/net. For the user's convenience of having all configuration in one single text file composed of variable assignments, of course. On my VM I configure network interfaces with a script that I run manually when I want to connect it to the network, instead of with an s6-rc service, but if you know, e.g., that you have wired network interface, you know that the predictable name assigned to it by the udev daemon is enp0s3, and you know that you want to use dhcpcd, you probably can write a simple dhcpcd@enp0s3 longrun that just calls the program with appropriate command-line arguments. That will work only for your particular computer, of course

I don't see anything in the Artix scripts for mtab, so that's something of note.

If /etc/mtab is a symbolic link to /proc/self/mounts, as it should, there's nothing to do about it.

The only other thing would be that in some of the OpenRC scripts' "depend" function there's "after", "before", etc and I'm not entirely sure if that's something needed or used in s6.

s6-rc-0.x.x.x only has a "depends on" relationship between services, that determines how many and which ones can start in parallel, and which ones serially after the ones they depend on. Or not at all, if one or more dependencies failed to start.

[alecStewart1]

A generic set would require much more work. And probably, until s6-rc-1.0.0.0 comes out, some kind of user-friendlier front-end (as a separate, ditribution-specific package) for creating the service set submitted to s6-rc-compile. I'm thinking of something e.g. Ncurses-based, like the kernel's make menuconfig.

I would be interested in contributing to a supportable and generic s6 configuration for Gentoo if I had more downtime. Although another big thing would potentially be having to put reminder messages for packages that come with a service for users to manually create the s6 script in /etc/s6/src or wherever and running s6-rc-compile after installation.

I don't know how this could be used in Gentoo, but there is Obarun's suite66. I also have heard Adelie Linux uses s6 as well.

Anyway I know the nice thing is that I can just create scripts that are specific to my system, at least.

I'll probably finish up with the scripts I need this weekend and go over the process of switching to s6 from OpenRC before I make the switch.

[GDH-gentoo]

Code: Select all

socklog-daemon
socklog-logger

Now that s6-2.11.1.2 is in Gentoo's repository (and on the stable amd64 branch!) I should probably use s6-socklog here instead and uninstall app-admin/socklog.

[...], but if you know, e.g., that you have wired network interface, you know that the predictable name assigned to it by the udev daemon is enp0s3, and you know that you want to use dhcpcd, you probably can write a simple dhcpcd@enp0s3 longrun that just calls the program with appropriate command-line arguments. That will work only for your particular computer, of course

Somewhat general (partial) service definition, but still without the full generality of net-misc/netifrc:

dhcpcd@enp0s3/type

Code: Select all

longrun

dhcpcd@enp0s3/run

Code: Select all

#!/bin/execlineb -P
s6-envdir data/env
/lib/s6-rc/service-helpers/dhcpcd@ enp0s3

dhcpcd@enp0s3/down-signal

Code: Select all

SIGALRM

dhcpcd@enp0s3/data/env/dhcpcd_options

Code: Select all

dhcpcd options like e.g. --timeout 10...

/lib/s6-rc/service-helpers/dhcpcd@

Code: Select all

#!/bin/execlineb -S1
background -d { echo "Starting dhcpcd on interface "${1} }
importas -su opts dhcpcd_options
dhcpcd --nobackground $opts $1

Then, with this definition:

net/type

Code: Select all

bundle

Code: Select all

$ ls -1 net/contents.d
dhcpcd@enp0s3

s6-rc -u change net would set up the network interface manually, and adding service "net" to the bundle started by /etc/s6-linux-init/current/scripts/rc.init would set it up automatically when the computer boots.

The service definition is partial because dependency specifications (i.e. dhcpcd@enp0s3/dependencias.d/* files) are likely needed. It should probably at least depend on the udev daemon being up, to make sure that all kernel modules and firmware needed for network interfaces like enp0s3 to appear are loaded. Which reminds me: in my experience, service readiness notification is very much needed for the correct operation of a parallel service manager. I have mostly resorted to polling with s6-notifyoncheck; systemd-udevd in particular is polled for readiness on my VM with the command udevadm control --start-exec-queue.

Although another big thing would potentially be having to put reminder messages for packages that come with a service for users to manually create the s6 script in /etc/s6/src or wherever and running s6-rc-compile after installation.

My ideal setup would be something like this:

1) The package manager installs helper scripts (e.g. in /lib/s6-rc/service-helpers), service definitions in s6-rc-compile source format and service definition templates (e.g. in /usr/share/s6-rc).
2) A front end (e.g. Ncurses-based) builds a service database in source format (e.g. in /var/lib/s6-rc/database-name) by symlinking service definitions and generating files (some of them possibly from templates), based on user selections and user configuration files (e.g. in /etc/s6-rc/conf.d), perhaps also doing some kind of (overridable) autodetection. Like autocreating a dhcpdc@network-interface longrun, based on detected network interfaces, if the user specified that (s)he wants to use dhcpcd, or autoadding a oneshot that activates LVM2 logical volume groups with vgchange, or a oneshot that opens LUKS2 containers with cryptsetup, as a dependency of the service that mounts local file systems if /etc/fstab specifies the mounting of their contained filesystems, etc.
3) The front end runs s6-rc-compile to compile the service database (e.g. to /etc/s6-rc/db/database-name).
4) Optionally, the front end makes the database live with s6-rc-update and/or makes it the boot time database (by updating the /etc/s6-rc/compiled symlink).

I don't know how this could be used in Gentoo, but there is Obarun's suite66.

It is a front end for s6 and s6-rc, and Obarun ships services as 66 service definitions, but I believe it also replaces s6-linux-init.

[alecStewart1]

Now that s6-2.11.1.2 is in Gentoo's repository (and on the stable amd64 branch!) I should probably use s6-socklog here instead and uninstall app-admin/socklog

You probably know more than me but in the /examples directory of the s6 repo has an example of syslogd-like functionality using s6-log and s6-socklog.

Wish there were more examples in that directory. I appreciate the amount of documentation around s6 and it's tools...but I really wish there was just a simple and straight forward "Here's how to write practical set of services" part of the documentation.

If it's there, I haven't stumbled upon it.

Although it is mentioned here

This whole page may sound very theoretical, dry, wordy, and hard to grasp without a live example to try things on; unfortunately, s6 cannot provide live examples without becoming system-specific.

There's one thing I'm curious about that I can't find in the documentation for s6 is nested services.

If you look at Artix's iwd it's structure looks like this:

Code: Select all

- iwd
--- iwd-log
----- consumer-for
----- notification-fd
----- pipeline-name
----- run
----- type
--- iwd-srv
----- dependendies.d
------- dbus
------- udevadm
----- producer-for
----- run
----- type
--- iwd.conf

So...is this not technically a bundle? Or can you define services like this with subservies?

EDIT:

Another question would be about this modules-load script in the Artix's s6-scripts repo. Gentoo's (or rather OpenRC's) /etc/init.d/modules script seems more involved due to needing to be generic, but would this suffice?

Code: Select all

#!/bin/sh
# modules-load [-n] [-v] - modules-load.d(5) compatible kernel module loader

export PATH=/bin:/sbin

{
# Parameters passed as modules-load= or rd.modules-load= in kernel command line.
sed -nr 's/,/\n/;s/(.* |^)(rd\.)?modules-load=([^ ]*).*/\3/p' /proc/cmdline

# Find files /{etc,run,usr/lib}/modules-load.d/*.conf in that order.
find -L /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d \
       	-maxdepth 1 -name '*.conf' -printf '%p %P\n' 2>/dev/null |
# Load each basename only once.
	sort -k2 -s | uniq -f1 | cut -d' ' -f1 |
# Read the files, output all non-empty, non-comment lines.
	tr '\012' '\0' | xargs -0 -r grep -h -v -e '^[#;]' -e '^$'
} |
# Call modprobe on the list of modules
tr '\012' '\0' | xargs -0 -r modprobe -ab "$@"

I'm no shell script wizard but from looking at the OpenRC module script and the following, it actually might.

[capezotte]

There's one thing I'm curious about that I can't find in the documentation for s6 is nested services.

If you look at Artix's iwd it's structure looks like this:

Code: Select all

- iwd
--- iwd-log
----- consumer-for
----- notification-fd
----- pipeline-name
----- run
----- type
--- iwd-srv
----- dependendies.d
------- dbus
------- udevadm
----- producer-for
----- run
----- type
--- iwd.conf

So...is this not technically a bundle? Or can you define services like this with subservies?

There are no subservices. These iwd services make a pipeline. It's documented in the s6-rc-compile html docs and it indeed creates a bundle:

The last consumer may also declare a name for the whole pipeline, in its pipeline-name file. If it does so, then a bundle is automatically created with the given name, and it contains all the services in the pipeline.

Note that iwd-srv and iwd-log are installed as individual services:
- $S6_RC_DB/iwd-srv and $S6_RC_DB/iwd-log
not
- $S6_RC_DB/iwd/iwd-srv and $S6_RC_DB/iwd/iwd-log

If you did the latter, s6-rc-compile would complain you are creating a service named iwd without a type.

Another question would be about this modules-load script in the Artix's s6-scripts repo. Gentoo's (or rather OpenRC's) /etc/init.d/modules script seems more involved due to needing to be generic, but would this suffice?

Works for me™. Reading the OpenRC script, it seems to mostly do the exact same steps, except doing everything within the shell to avoid relying on coreutils (which, on more "exotic" systems, might not have all the options this script relies on -- find -printf is not standard, for instance).

[GDH-gentoo]

Although it is mentioned here

This whole page may sound very theoretical, dry, wordy, and hard to grasp without a live example to try things on; unfortunately, s6 cannot provide live examples without becoming system-specific.

Exactly. Mandating that every GNU/Linux distribution adopt the One True Boot Sequence™ is a systemd thing In my book, upstream service managers writers provide mechanism, upstream application writers provide documentation, and distributions provide policy and service definitions for their supported service manager(s) that implement that policy.

If you look at Artix's iwd it's structure looks like this:

What capezotte said. That's two s6-rc longruns joined by a pipeline; iwd-srv starts the iwd daemon, iwd-log provides a dedicated logger, and, because iwd-log's definition contains a pipeline-name file, s6-rc-compile automatically creates a bundle whose name is iwd, and whose contents are iwd-srv and iwd-log. So, for example, doing s6-rc -u change iwd starts both the iwd daemon and its logger.

Another question would be about this modules-load script in the Artix's s6-scripts repo. Gentoo's (or rather OpenRC's) /etc/init.d/modules script seems more involved due to needing to be generic, but would this suffice?

Maybe. Both scripts process the contents of the systemd-style modules-load.d directories and end up calling modprobe, only with different strategies. OpenRC's modules script only relies on the shell, shell builtins and the sort and printf utilities. Also, it is larger because it also processes /etc/conf.d/modules, which was the way old OpenRC dealt with on-demand kernel modules before systemd de facto standarized modules-load.d (current OpenRC handles both). Artix' script relies on the sed, sort, find, cut, grep, uniq, tr and xargs utilities. So personally, I prefer how OpenRC does it, although I don't like printf in a service script that might run before local filesystems are mounted.

On my VM with an s6-based init system, neither /etc/modules-load.d nor /usr/lib/modules-load.d exist, so I don't need an s6-rc service for processing their contents The udev daemon automatically loads all needed kernel modules.

[alecStewart1]

There are no subservices. These iwd services make a pipeline. It's documented in the s6-rc-compile html docs and it indeed creates a bundle:

The last consumer may also declare a name for the whole pipeline, in its pipeline-name file. If it does so, then a bundle is automatically created with the given name, and it contains all the services in the pipeline.

What capezotte said. That's two s6-rc longruns joined by a pipeline; iwd-srv starts the iwd daemon, iwd-log provides a dedicated logger, and, because iwd-log's definition contains a pipeline-name file, s6-rc-compile automatically creates a bundle whose name is iwd, and whose contents are iwd-srv and iwd-log. So, for example, doing s6-rc -u change iwd starts both the iwd daemon and its logger.

Oh, that's kinda neat!

Reading the OpenRC script, it seems to mostly do the exact same steps, except doing everything within the shell to avoid relying on coreutils (which, on more "exotic" systems, might not have all the options this script relies on -- find -printf is not standard, for instance).

Hm well I don't think I personally have a more "exotic" system so maybe it'll work fine for my use cases.

The udev daemon automatically loads all needed kernel modules.

Is this considered to be more portable or sane? I don't have anything in /etc/modules-load.d nor /usr/lib/modules-load.d either.

[GDH-gentoo]

The udev daemon automatically loads all needed kernel modules.

Is this considered to be more portable or sane?

Unless you are NeddySeagoon, it is what happens by default on any [GNU/]Linux computer with a running udev daemon... including mine

I don't have anything in /etc/modules-load.d nor /usr/lib/modules-load.d either.

Then, for your particular use case, you don't need to worry either.

/etc/modules-load.d is populated by the administrator, i.e. likely you in this case. So if you needed it, you'd already know

/usr/lib/modules-load.d is populated by the package manager, when it installs packages that provide a kernel module that would be needed for something, but won't be automatically loaded by the udev daemon. If you don't have that directory, then you haven't installed any such package.

[capezotte]

The udev daemon automatically loads all needed kernel modules.

Is this considered to be more portable or sane? I don't have anything in /etc/modules-load.d nor /usr/lib/modules-load.d either.

It's the foundation of hotplugging and automatic hardware detection on Linux. It's perfectly fine to rely on it (as do pretty much 100% of Linux distros, even non-GNU ones).

I'd still recommend adding a modules-load.d service on real machine, in case a package installs one of these files or you want to load a module like zram that isn't hardware related (so it won't be auto-loaded by udev).

[alecStewart1]

Just wanted to put here that I have a repo for the s6 scripts I have so far. Feel free to point out mistakes in there if you're interested and I would ask about what I have in this section of the README.

[Wewfus]

Hello, I am interested in using s6 as an OpenRC/systemd replacement. I have been reading the various wikis and will check out the repo linked above.

I was just wondering if anyone has been running it as their daily init/services manager on their desktop and if there have been any more tips about using it day-to-day in Gentoo since the last reply from last year.

I don't understand why s6 isn't more popular. It seems like it provides everything people say they like about systemd in a much cleaner interface and much smaller code base. Is there some issue with the license it's released under or something? I don't see many distros opting to use it. Everyone claims it's complicated to work with but the docs don't make it seem that way and my limited experience with it on VMs has been good.

Has anyone attempted to use s6-ipcserver as a dbus replacement? Is it possible to make dbus aware applications use it for their IPC server instead? I have been thinking about trying to write a dbus-front end for s6-ipcserver. But I'm not sure how much work it would be to make dbus aware applications work with it instead.

What about mdevd? (https://skarnet.org/software/mdevd/mdevd.html)

I was thinking of using it as udev replacement once I find the time to go down that rabbit hole.

I'll try to remember to come back and update this thread once I switch my bare metal stuff from OpenRC over to s6. I've been meaning to do it for about two years now but I didn't have a good machine to test it on before deploying it on the rest of my network. Now that I have a dedicated dev box I'm looking forward to finally getting it done. I think Portage+s6 would make for a great Gentoo-derived distro. I'm really surprised no one has done it yet. I know some of the Arch guys have been working with s6 over the last few years but I don't see many people in the Gentoo community talking about the s6 suite of tools. From what I can tell they're really well put together and documented. I suppose OpenRC is still preferred because it has been the default for so long. I feel like if systemd didn't have all that funding and advertising behind it people would have switched over to s6 long ago if they needed something more than runit and similar inits provide.

I can already say that I much prefer working with s6 compared to systemd. It's a really good service manager and it doesn't do anything funky. I'm not trying to hate on systemd (I don't like it but I do use it every day on my non-Gentoo servers and systems).

[GDH-gentoo]

I was just wondering if anyone has been running it as their daily init/services manager on their desktop and if there have been any more tips about using it day-to-day in Gentoo since the last reply from last year.

Same as you apparently, on a rather simplistic Gentoo VM (only SDDM + Openbox + elogind, X11, no network services provided), but for quite some time now, including having endured several world updates It is on profile default/linux/amd64/17.1/desktop, and planned to be on default/linux/amd64/23.0/split-usr/desktop some time in the next 12 months , so, from Gentoo's point of view, it counts as a split /usr, OpenRC-based system.

It's not built with the Artix service definitions though, I wrote my own based on Gentoo's OpenRC scripts and trying to follow closely what they do —which I'm not sure Artix's set does—. It works, in the sense that an init system (and its service manager) that works is essentially one that you don't notice that it's there

I don't understand why s6 isn't more popular. It seems like it provides everything people say they like about systemd in a much cleaner interface and much smaller code base. Is there some issue with the license it's released under or something? I don't see many distros opting to use it. Everyone claims it's complicated to work with but the docs don't make it seem that way and my limited experience with it on VMs has been good.

Because distribution developers would need to write and maintain a set of "official" s6-rc service definitions to be able to claim that they support an s6-based init system. This is work that requires time and energy that is not always available, even if the motivation happened to be there and the learning of the (current) mechanisms was done.

Has anyone attempted to use s6-ipcserver as a dbus replacement? Is it possible to make dbus aware applications use it for their IPC server instead? I have been thinking about trying to write a dbus-front end for s6-ipcserver. But I'm not sure how much work it would be to make dbus aware applications work with it instead.

The way that s6-ipcserver works and the way that D-Bus works aren't really compatible. The D-Bus design has a bus daemon with a many to one connection model, and s6-ipcserver is a superserver, with a one to one connection to several processes running the same server program model.

It is possible to start the system-wide message bus from s6-rc, though.

What about mdevd? (https://skarnet.org/software/mdevd/mdevd.html)

It probably works, but has the same 'adoption problem' that BusyBox mdev has: you just can't use it with software written to link to libudev.

It is possible to start systemd-udevd from Gentoo's sys-apps/systemd-utils from s6-rc, though.

I suppose OpenRC is still preferred because it has been the default for so long.

And supported. You get accompanying service scripts from the package manager without really noticing, so many people probably have the opinion that "OpenRC just works". So yeah, that's a factor.

[alecStewart1]

Hello, I am interested in using s6 as an OpenRC/systemd replacement. I have been reading the various wikis and will check out the repo linked above.
I don't understand why s6 isn't more popular. It seems like it provides everything people say they like about systemd in a much cleaner interface and much smaller code base. Is there some issue with the license it's released under or something? I don't see many distros opting to use it. Everyone claims it's complicated to work with but the docs don't make it seem that way and my limited experience with it on VMs has been good.

To piggyback off of what GDH-gentoo said, s6 still has some minor learning curve for it, and by s6 I really mean execline, the little scripting language that you see a lot of the Artix s6 scripts written in. It's a question of "what do we have to do to make these scripts generic for 99% of users?"

I put in the README of the project I linked earlier:

Eventually it may be interesting to create more general scripts and even potentially turn this into an overlay in order to help give Gentoo better or even official s6 support.

In the subheading below that:

"Are you using these yourself?"

Currently (as of <2024-02-10 Sat>) i am not. Life gets in the way of a lot of things, and the base OpenRC configuration that Gentoo provides works for me so far.

And in the TODO section:

I’m getting a better understanding of how s6 works and how to create s6 services, so not everything is here yet.

Eventually I would like to figure out how to make that repo into an actual overlay, something more official, but that's something I'd also have to learn more about as well. Maybe that's something I focus on next in my personal time, that isn't finishing video games or configuring Emacs some more.

[flexibeast]

A few notes:

* s6 doesn't need execline used for service scripts. Use of execline is certainly encouraged, because execline is far more efficient for this particular use-case than laoding up an entire shell interpreter (even a basic POSIX-oriented one like dash), but service scripts can be written to use any interpreter one can put on the shebang line (including e.g. python). Of course, it's probably better to be as consistent as possible regarding the interpreter one uses, for ease of maintenance, and re-use of existing service scripts does mean learning execline.

* Various people are using s6 for service management, as well as for service supervision. It's certainly possible to do that, but i feel it's typically better to use s6-rc for service management (e.g. starting / stopping / restarting service); that's what it was created for. To me, using s6 rather than s6-rc in this context is like using a lower-level programming language rather than a higher-level one - if one doesn't actually have requirements forcing the use of the lower-level language, using the higher-level language might make various things easier.

* i'm (very slowly) working on setting up my system to use s6-rc to manage user services, since OpenRC doesn't yet provide that functionality (though it's gradually being worked on). i'm hoping to write up the process of doing so in the form of a 'quickstart' guide for the wiki, and also add s6-rc scripts to my overlay. Refer to this thread on the 'supervision' list for some more details.

(More generally, refer to my user page on the wiki for various s6-related stuff, e.g. links to various people's work, including alecStewart1's repo.)

[alecStewart1]

A few notes:

* s6 doesn't need execline used for service scripts. Use of execline is certainly encouraged, because execline is far more efficient for this particular use-case than laoding up an entire shell interpreter (even a basic POSIX-oriented one like dash), but service scripts can be written to use any interpreter one can put on the shebang line (including e.g. python). Of course, it's probably better to be as consistent as possible regarding the interpreter one uses, for ease of maintenance, and re-use of existing service scripts does mean learning execline.

Yes, of course. Though I imagine that if we're aiming to create more generalized scripts for multiple people to use, I'd rather avoid doing stuff in Python.

* Various people are using s6 for service management, as well as for service supervision. It's certainly possible to do that, but i feel it's typically better to use s6-rc for service management (e.g. starting / stopping / restarting service); that's what it was created for. To me, using s6 rather than s6-rc in this context is like using a lower-level programming language rather than a higher-level one - if one doesn't actually have requirements forcing the use of the lower-level language, using the higher-level language might make various things easier.

Sorry, yes, that's what I meant when I say "s6". The repo I started is eventually for replacing OpenRC entirely on ones system.

* i'm (very slowly) working on setting up my system to use s6-rc to manage user services, since OpenRC doesn't yet provide that functionality (though it's gradually being worked on). i'm hoping to write up the process of doing so in the form of a 'quickstart' guide for the wiki, and also add s6-rc scripts to my overlay. Refer to this thread on the 'supervision' list for some more details.

(More generally, refer to my user page on the wiki for various s6-related stuff, e.g. links to various people's work, including alecStewart1's repo.)

Sounds great! I might start working on some more stuff myself.

[flexibeast]

if we're aiming to create more generalized scripts for multiple people to use, I'd rather avoid doing stuff in Python.

Oh definitely agreed! And not only because i'm not that familiar with Python. Yeah, for those of us generally familiar with the s6 ecosystem, and wanting to develop scripts with the intent of others using them, i think using execline is the way to go. But i also want people to be aware that if there's a service they need for which something hasn't already been built, they can use a language they're familiar with (even if only for initial prototyping).

Sorry, yes, that's what I meant when I say "s6". The repo I started is eventually for replacing OpenRC entirely on ones system.

Ah! i see - sorry for my misunderstanding.

Well, would you be willing for your repo to contain 'user services' as well as system services? If so, i'd happily submit PRs for the user services i'm developing, and then the relevant packages in my overlay can be based on your repo.

]Sounds great! I might start working on some more stuff myself.

Excellent!

[alecStewart1]

Ah! i see - sorry for my misunderstanding.

Well, would you be willing for your repo to contain 'user services' as well as system services? If so, i'd happily submit PRs for the user services i'm developing, and then the relevant packages in my overlay can be based on your repo.

It does.

https://codeberg.org/alecStewart1/gento ... r/services

If that's what you consider "user services" that is.

I don't know if this would be useful or not, but I think if this were to become an overlay of sorts, creating an eclass could be useful. Then if Gentoo s6 support were to become more supported, packages could have a s6 USE flag and any functionality needed to add services scripts would be in the eclass. Maybe this is too ambitious at the moment, but it's something to think about.

[flexibeast]

Well, in this context, "user services" are services that aren't run system-wide, but by and for a specific user, under that user's login and environment. Most of the services in that directory involve software not typically intended to be run as user services, but as system-wide services: `chrony`, `elogind`, `iwd`, `sddm`, `ufw`, etc.

The `dbus` service in your repo runs a _system_ bus, but not a _session_ bus; one of the user services i want is a D-Bus session bus. This service would, for example, be a dependency of the `emacs` user service, so that Emacs runs with an appropriate value for DBUS_SESSION_BUS_ADDRESS (which it doesn't when it's started either as a system-wide service, or before the session bus address is determined).

So i would suggest that there should be distinct directories of services intended to be run as system services, and those that should be run as user services: the existing `dbus` service would go in the former, a new `dbus-session` service would go in the latter, and the existing `emacs` service would depend on the `dbus-session` service.

Re. the eclass, well, there's already the s6.eclass, https://github.com/gentoo/gentoo/blob/m ... /s6.eclass; are you thinking of specific functionality needing to be added to that?