| View previous topic :: View next topic |
| Author |
Message |
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
 Posted: Sun Nov 13, 2022 2:59 am Post subject: From OpenRC to s6: Any tips? |
 |
|
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: |
#!/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: |
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: |
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. |
|
| Back to top |
|
 |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sun Nov 13, 2022 3:35 pm Post subject: Re: From OpenRC to s6: Any tips? |
|
|
| alecStewart1 wrote: | | 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: | # 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: | 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 |
| alecStewart1 wrote: | | 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 
| alecStewart1 wrote: | | 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.
| alecStewart1 wrote: | | 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
| Posted: Tue Nov 15, 2022 5:42 pm Post subject: Re: From OpenRC to s6: Any tips? |
|
|
| GDH-gentoo wrote: |
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. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sat Nov 19, 2022 4:10 pm Post subject: Re: From OpenRC to s6: Any tips? |
|
|
| GDH-gentoo wrote: | | Code: | 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.
| GDH-gentoo wrote: | | [...], 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
dhcpcd@enp0s3/run
| Code: | #!/bin/execlineb -P
s6-envdir data/env
/lib/s6-rc/service-helpers/dhcpcd@ enp0s3 |
dhcpcd@enp0s3/down-signal
dhcpcd@enp0s3/data/env/dhcpcd_options
| Code: | | dhcpcd options like e.g. --timeout 10... |
/lib/s6-rc/service-helpers/dhcpcd@
| Code: | #!/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: | $ 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.
| alecStewart1 wrote: | | 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).
| alecStewart1 wrote: | | 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
| Posted: Sun Nov 27, 2022 4:35 am Post subject: |
|
|
| GDH-gentoo wrote: |
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
| Quote: |
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: |
- 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: |
#!/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. |
|
| Back to top |
|
|
capezotte
n00b
Joined: 13 Nov 2022
Posts: 7
Location: South America
|
| Posted: Sun Nov 27, 2022 2:25 pm Post subject: |
|
|
| alecStewart1 wrote: |
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: |
- 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.
| alecStewart1 wrote: |
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). |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sun Nov 27, 2022 4:52 pm Post subject: |
|
|
| alecStewart1 wrote: | Although it is mentioned here
| Quote: |
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.
| alecStewart1 wrote: | | 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.
| alecStewart1 wrote: | | 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
| Posted: Mon Nov 28, 2022 9:48 pm Post subject: |
|
|
| capezotte wrote: |
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.
|
| GDH-gentoo wrote: |
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!
| capezottre wrote: |
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.
| GDH-gentoo wrote: |
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. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Mon Nov 28, 2022 11:02 pm Post subject: |
|
|
| alecStewart1 wrote: | | GDH-gentoo wrote: |
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
| alecStewart1 wrote: | | 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
capezotte
n00b
Joined: 13 Nov 2022
Posts: 7
Location: South America
|
| Posted: Tue Nov 29, 2022 12:21 am Post subject: |
|
|
| alecStewart1 wrote: |
| GDH-gentoo wrote: |
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). |
|
| Back to top |
|
|
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
| Posted: Mon Jan 16, 2023 10:25 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Wewfus
n00b
Joined: 23 Mar 2024
Posts: 2
|
| Posted: Mon Mar 25, 2024 10:54 am Post subject: |
|
|
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). |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Mon Mar 25, 2024 1:27 pm Post subject: |
|
|
| Wewfus wrote: | | 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
| Wewfus wrote: | | 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.
| Wewfus wrote: | | 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.
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.
| Wewfus wrote: | | 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
| Posted: Wed Apr 10, 2024 3:28 pm Post subject: |
|
|
| Wewfus wrote: | 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:
| Quote: |
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:
| Quote: |
"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:
| Quote: |
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.  |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Thu Apr 11, 2024 1:33 am Post subject: |
|
|
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.) |
|
| Back to top |
|
|
alecStewart1
Tux's lil' helper
Joined: 03 Jul 2022
Posts: 122
|
| Posted: Thu Apr 11, 2024 9:19 pm Post subject: |
|
|
| flexibeast wrote: | 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.
| flexibeast wrote: |
* 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.
| flexibeast wrote: |
* 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. |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Fri Apr 12, 2024 6:17 am Post subject: |
|
|
| alecStewart1 wrote: | | 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).
| alecStewart1 wrote: | | 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.
| alecStewart1 wrote: | | ]Sounds great! I might start working on some more stuff myself. |
Excellent! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
