Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [Tracker] s6 support (Read 7664 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[Tracker] s6 support

This is the thread for tracking s6 support in Artix. Check the out the wiki page as well.

What is it?
s6 is a daemontools-like init system, service manager, and process supervisor.

How does it compare to runit or openrc?
s6 has more in common with runit since runit is also daemontools-like, but it is a bit more complex. One of the main strengths of s6 is its ability to guarantee proper service dependency management as well as truly parallelized service startup. runit is parallel, but it requires scripts to manually write a check function which may not be perfect. Openrc's dependency management works well but its parallel implementation is still considered experimental since it can possibly lock the machine during boot. See the author's page for a little more of his argument.

Current status:
Available in the stable repos plus all of the scripts from runit.

Installation:
Of course, this will remove your old init and change to a new one so as always, proceed with caution. skalibs, execline, s6, s6-rc, and s6-linux-init are mandatory packages (pacman -S s6 will pull all of these). Additionally, many service scripts are available (suffixed with *-s6). It's also strongly recommended that you at least get dhcpcd-s6 for internet.

Some shell scripts are located in /etc/s6/current/scripts which are executed at every bootup and shutdown by s6-linux-init Additionally an /etc/s6/rc.local script is executed by s6-rc on bootup. You can modify any of them to your liking if need be. After a reboot, you should have a working and functional s6 system.

Hopefully the reboot goes smoothly without any hitches. Now that you are actually running an s6-based system, you can start customizing your services and playing with the s6-rc database. The s6-rc packages are configured to start the "default" bundle if it exists on boot. You can add any services you want to a bundle. This is basically like using openrc's runlevels. So to add services to the default bundle you can simply do this:
Code: [Select]
# s6-rc-bundle add default dhcpcd elogind
Note that due to the way s6-rc's database works, you have to first delete a bundle (s6-rc-bundle delete "name") and then add it again if you want to modify it. "agetty-tty1" is provided by the s6-init binary itself while tty2-6 are started up in the initial boot. To bring the bundle up it's just simply:
Code: [Select]
# s6-rc -u change default

Of course, you can also individual start services in the same way. So for example:
Code: [Select]
# s6-rc -u change dhcpcd

I won't be covering all possible usage here (please consult s6-rc's faq for more details) but here are some quick tips. s6-rc uses a database approach to managing services which makes it a little more complex. The s6 packages I put together hide most of the boilerplate in the background so you shouldn't have to worry too much about it (scripts are installed in /etc/s6/sv if you need to know), but look at s6's documentation if you want more details.

To bring up a service/bundle:
Code: [Select]
# s6-rc -u change service

To bring down a service/bundle:
Code: [Select]
# s6-rc -d change service

To list all available services:
Code: [Select]
# s6-rc -d list

To generate a new database:
Code: [Select]
# s6-rc-compile /destdir /sourcedir

To update the database:
Code: [Select]
# s6-rc-update /path/to/compiled-database

Re: Unofficial s6 support guide

Reply #1
Updated the OP in light of the newest version of runit-rc being pushed to stable. If you had manually edited the file before, you can just do a quick "pacman -Sy --force runit-rc" to make sure the file gets overwritten with the upstream changes.

Re: Unofficial s6 support guide

Reply #2
Quote
There's no point in duplicating work if you don't have to
In this case why you don't use 66?
boot-66serv (complete set of service to boot properly your system): https://framagit.org/Obarun/boot-66serv (use the tag not the commit)
66 (complete set of tools to manage your service): https://framagit.org/Obarun/66 (use tag not the commit)
Complete Documentation are also available: http://web.obarun.org/software/
Set of service: https://framagit.org/pkg/observice
66 PKGBUILD: https://framagit.org/pkg/obcore/66 (use version not trunk)
boot-66serv PKGBUILD: https://framagit.org/pkg/observice/boot-66serv (use version not trunk)
Obarun : free to control your system

Re: Unofficial s6 support guide

Reply #3
To be quite honest, I haven't really looked into 66. I'll be sure to look at it in more detail in the future.

Re: [Tracker] s6 support

Reply #4
Great news. s6 support has made some progress over the weekend and is now (mostly) official. I've updated the OP of this thread to reflect that change. Various s6 packages are now available in the goblins repo (you will have to enable that in your /etc/pacman.conf). These will be in goblins for at least the time being since we're still at the experimental stage here.

If you had previously installed my s6 AUR packages, please replace them with the goblins version ASAP as there were some large changes. The main star of the show here (s6-linux-init; which actually makes and replaces your init) is still AUR only since we need to figure out how to integrate it with artix-sysvcompat, but everything else is in the repos now.

If you have any service script requests and or just general questions feel free to ask me here (or in IRC). A future goal of mine is to figure out how to port s6 service scripts to execline (a different scripting language made specifically for s6), but for now I'm just doing them in shell since they work fine. And "doing them" might be a bit too much of an exaggeration because most of the time it's just copying the runit script with a few modifications.

Re: [Tracker] s6 support

Reply #5
Goblins repo? Do you mean gremlins?

Edit: Ah it is indeed goblins, thought it was an error.
Assuming s6 doesn't do some of those out of the box there are quite a couple of services in the boot runlevel of openrc that might need a script for a conversion, namely dmcrypt.

Re: [Tracker] s6 support

Reply #6
Artix
Arch
systemcore
worldextra
galaxycommunity
lib32multilib
gremlinstesting
goblinsstaging
galaxy-gremlinscommunity-testing
lib32-gremlinsmultilib-testing
galaxy-goblinscommunity-staging
lib32-goblinsmultilib-staging

 

Re: [Tracker] s6 support

Reply #7
Oh I see, I was purely going from the commented pacman.conf

Re: [Tracker] s6 support

Reply #8
Oh I see, I was purely going from the commented pacman.conf


Normally, you don't really want to use the goblins repos, unless you know exactly what you are doing.
These repos contain rebuilds, and chances are high you break your system if you catch eg with s6 other updates as it currently also contains llvm9.

s6 is parked there until deemed to not be breaking any depends with other inits, once all works as expected, s6 packages will move in gremlins.

Re: [Tracker] s6 support

Reply #9
Apologies, the information the OP is a tad outdated. If you're careful, you can use the s6 goblins packages right now (which has everything for a basic s6 system) but you would need to force an install of runit-rc somehow otherwise your system won't be too useful (dev/sys/proc/ doesn't mount, no cgroups, etc.). Currently the hold up is that I need to put together a package that contains a list of oneshot startup services for s6 and make that a dependency. Runit-rc does actually accomplish this, but it makes more sense to launch it in a way that actually integrates with s6 (namely s6-rc).

Assuming s6 doesn't do some of those out of the box there are quite a couple of services in the boot runlevel of openrc that might need a script for a conversion, namely dmcrypt.

dmcrypt actually works with runit-rc (I'm using on this machine right now in fact), but yes the plan is for it to be provided as part of a set of oneshot startup scripts for s6-rc.

Re: [Tracker] s6 support

Reply #10
Okay there's some more news on this front. The various s6 packages have been promoted from goblins to gremlins now (i.e. staging to testing). The big major change is that s6 now comes with a set of various startup oneshot scripts that are executed on boot. This essentially replaces runit-rc and drops that as a dependency.

For the future, I will probably add a conf file for the startup scripts to add some more options. It's technically not as configurable as runit-rc at the moment (for example, cgroups are only hybrid and the hardware clock is only UTC), but in general it should work. The only major thing not implemented at the moment is reading /etc/crypttab configuration so don't attempt to switch if you depend on those for boot.

If someone finds anything wrong, please let me know. There's more things to do. But I think we've pretty much stabilized the main parts of this.

Re: [Tracker] s6 support

Reply #11
As a heads up, the /etc directories for s6, s6-rc, and s6-linux-init have all been collapsed into /etc/s6 for simplier, saner organization (before they were scattered a bit). /etc/s6/sv is the location of the service definition directories. /etc/s6/rc is where the compiled database is stored. /etc/s6/skel contains the skeleton rc scripts for boot/shutdown. And /etc/s6/current contains the run-image, scripts, and binaries created by s6-linux-init-maker. I should have done this way earlier because it autocompletes so much better.

On the script front, I did add lvm and cryptsetup support to the initial oneshots. They should work (at least there's no errors when executing), but I'll admit I have not tested them. My encrypted setups don't actually use /etc/crypttab configuration but unlock with the initramfs. Also, the vast majority of the scripts are now in execline and not shell. I'm somewhat okay at writing execline now so I will stick to this in the future. The exception are the handful of very complicated oneshot scripts (like cgroups or cryptsetup) that I'm not sure yet how to port. Basically those are just a execline scripts that execute a sh command that executes the bash script.

Another thing to note, I have compiled s6-linux-init with the option to print all messages to /dev/console on startup. By default, your /dev/console is tty1 which means you will get a ton of messages on bootup by default. I have not made up my mind on how to handle this quite yet. The messages can be a little annoying, but also they can contain some very vital, important information. As a workaround you could set /dev/console to a different tty as part of your kernel's parameter (i.e. console=tty7 for grub) to get it to print somewhere else. Probably, I just need to think of something clever with logging.

Re: [Tracker] s6 support

Reply #12
Another thing to note, I have compiled s6-linux-init with the option to print all messages to /dev/console on startup. By default, your /dev/console is tty1 which means you will get a ton of messages on bootup by default. I have not made up my mind on how to handle this quite yet. The messages can be a little annoying, but also they can contain some very vital, important information. As a workaround you could set /dev/console to a different tty as part of your kernel's parameter (i.e. console=tty7 for grub) to get it to print somewhere else. Probably, I just need to think of something clever with logging.
I think logging should still use kernel console parameter instead of some else configured tty. This is not an issue for common x86_64 PCs but some ARMs may use strange ttys for kernel messages output (good example: firefly rk3399 has serial console as /dev/ttyFIQ0 and it can be problematic to have screen output at boot)
ARMtix

Re: [Tracker] s6 support

Reply #13
I think logging should still use kernel console parameter instead of some else configured tty. This is not an issue for common x86_64 PCs but some ARMs may use strange ttys for kernel messages output (good example: firefly rk3399 has serial console as /dev/ttyFIQ0 and it can be problematic to have screen output at boot)

Oh no worries, I'm not setting anybody's kernel console for them. That's out of the scope of s6. It's just whatever the default is for your bootloader.

Re: [Tracker] s6 support

Reply #14
Another big milestone has been reached. The parts of s6 and its init scripts are available in the stable repos now. A solid chunk of init scripts are there but I haven't finished porting everything yet. I'll try to finish adding in the missing scripts in the next few days.