Artix Linux Forum

Init systems => S6 => Topic started by: Dudemanguy on 12 September 2019, 01:11:58

Title: [Tracker] s6 support
Post by: Dudemanguy on 12 September 2019, 01:11:58
This is the thread for tracking s6 support in Artix. Check the out the wiki page (https://wiki.artixlinux.org/Main/S6) 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 (https://skarnet.org/software/s6/why.html) 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 (https://skarnet.org/software/s6-rc/faq.html) 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
Title: Re: Unofficial s6 support guide
Post by: Dudemanguy on 13 September 2019, 14:59:11
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.
Title: Re: Unofficial s6 support guide
Post by: obarun on 14 September 2019, 03:04:31
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)
Title: Re: Unofficial s6 support guide
Post by: Dudemanguy on 14 September 2019, 04:49:03
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.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 16 September 2019, 17:14:59
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.
Title: Re: [Tracker] s6 support
Post by: Relih on 06 October 2019, 14:20:31
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.
Title: Re: [Tracker] s6 support
Post by: SGOrava on 06 October 2019, 14:28:52
Artix
Arch
systemcore
worldextra
galaxycommunity
lib32multilib
gremlinstesting
goblinsstaging
galaxy-gremlinscommunity-testing
lib32-gremlinsmultilib-testing
galaxy-goblinscommunity-staging
lib32-goblinsmultilib-staging
Title: Re: [Tracker] s6 support
Post by: Relih on 06 October 2019, 15:49:29
Oh I see, I was purely going from the commented pacman.conf
Title: Re: [Tracker] s6 support
Post by: artoo on 06 October 2019, 17:43:32
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.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 08 October 2019, 14:37:32
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.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 25 October 2019, 23:08:34
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.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 28 October 2019, 04:49:07
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.
Title: Re: [Tracker] s6 support
Post by: phoenix_king_rus on 28 October 2019, 10:58:26
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)
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 28 October 2019, 20:02:11
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.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 02 November 2019, 03:57:41
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.
Title: Re: [Tracker] s6 support
Post by: jyf007 on 18 November 2019, 02:57:52
i have issue with s6-linux-init on initramfs,
it shows 
CPU 1 PID: 1 Comm: s6-linux-init Not tainted 5.3.9-artix1-1
then kernel panic not syncing Attempted to kill init
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 18 November 2019, 21:20:36
What initramfs are you using? Currently, the s6-linux-init package makes the assumption that you are using mkinitcpio. The /run directory already exists with mkinitcpio so the s6-linux-init is compiled with the option to remount the /run directory instead of trying to create it. The problem with this is that if you do not use mkinitcpio or some other initramfs that writes to /run; it will have a kernel panic. I haven't personally tested it but dracut (which is supposed to replace mkinitcpio in the future) probably doesn't do anything to /run, so in the future that compile-time option will need to be dropped.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 06 December 2019, 20:07:18
Not sure when this thread will become obsolete, but I made a fairly major change that is worth repeating here.

The s6-rc-db-update-hook has been rewritten  (currently, the new version of s6-rc is in testing; will be moved to system sometime later). The behavior is different now when adding/removing s6 services and (I think) it's better now. First of all, it does not delete any database directories anymore. That is left entirely up to the user. Of course this means that a new database directory is created everytime you install/uninstall a script from the repos, but in practice there's no reason anyone would do this constantly. There's a gentle reminder in the hook (which I think is worded OK; can change it if it's not clear enough though)  telling the user that he/she can remove unneeded/unwanted databases.

Additionally, the hook does its best to preserve old bundles from the old database so you don't have to remake bundles when you install a script from the repo. This basically done in two steps. First: see if there are any bundles that existed in the old database that don't exist in the new one (i.e. bundles added with the s6-rc-bundle command). And then secondly, find the services in the old bundle that still exist in the new database and recreate the old bundle. This way, if you uninstall a service that's part of a bundle, the hook will recognize this and remake the bundle without trying to add the service you removed (which would result in an error of course).
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 17 December 2019, 16:08:39
The latest versions of s6/s6-rc have some changes + new features. The biggest change is that eudev-s6 is now obsolete and merged into s6-rc. The older behavior  attempted to mimic runit, but upon reflection that was not necessary since runit's concept of stage 1/2/3 isn't really relevant to s6. We want to start udevd as early as possible (before mounting filesystems) so therefore this means we should include it with the initial set of bootup scripts and allow s6 to supervise it from there on. So udevd is always started and you no longer need to include it any custom made bundles.

As for new features, an /etc/s6/s6.conf file is now included and used. This mimics runit's rc.conf and allows you to choose what hardware clock to use as well as what cgroups to use. The syntax is a little different; just foo=value, no spaces or quotes allowed. For the vast majority of use cases, the default UTC and hybrid cgroups is what you want. Also, s6 now uses modules-load during startup so you can load kernel modules on boot using s6. See man modules-load. It's pretty straightforward.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 31 December 2019, 17:46:10
Another new feature added. s6 now supports an /etc/s6/rc.local file in which you can execute arbitrary commands on bootup (openrc and runit have an equivalent). By default, it execute immediately on bootup but as a nice s6 bonus, you can alter the rc-local service to wait on some other service to be up. Just navigate to /etc/s6/sv/rc-local, edit the dependencies file in there and then recompile/update the database (sh /usr/share/libalpm/scripts/s6-rc-db-update-hook). So for example, if you want to wait for filesystems to be mounted first, you can just add a "mount-filesystems" line in that file. As a aside, /etc/rc.local will be executed instead if it exists.
Title: Re: [Tracker] s6 support
Post by: dnkl on 02 January 2020, 19:22:55
Thanks for keeping the improvements coming!

Nit: why are all the files executable?
Title: Re: [Tracker] s6 support
Post by: nous on 02 January 2020, 21:50:12
By default, it execute immediately on bootup
Please pardon my s6-ignorance, is it executed before or after / gets mounted rw?

but as a nice s6 bonus, you can alter the rc-local service to wait on some other service to be up. Just navigate to /etc/s6/sv/rc-local, edit the dependencies file in there and then recompile/update the database (sh /usr/share/libalpm/scripts/s6-rc-db-update-hook). So for example, if you want to wait for filesystems to be mounted first, you can just add a "mount-filesystems" line in that file.
This better fits the usual rc.local role, but I also like the option of executing as early at bootup as possible. In OpenRC it gets executed last, which sometimes is not handy.

As a aside, /etc/rc.local will be executed instead if it exists.
So, /etc/rc.local overrides /etc/s6/sv/rc-local?
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 03 January 2020, 01:24:43
Nit: why are all the files executable?

Honest answer: because I've lazily copy and pasted 755 permissions everywhere even though plenty of files only need 644. You're right. It needs fixing.

Please pardon my s6-ignorance, is it executed before or after / gets mounted rw?

Before. It's started in parallel at the very beginning of boot so yeah the only thing you're allowed to assume is that you have /usr/bin.

Quote
So, /etc/rc.local overrides /etc/s6/sv/rc-local?

Yeah, I thought this was the best compromise. I like that all the s6 stuff neatly installs into /etc/s6 and wanted to keep it that way. But sometimes there might be some general artix things we want (AKA branding), so we don't want to juggle too much init-specific logic.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 06 January 2020, 00:16:45
New versions of some s6 stuff pushed into system. Here's some brief changes/fixes.

Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 13 January 2020, 04:41:16
I've split out the startup/shutdown scripts that installed with s6-rc to their own separate package, s6-scripts. Bumping the build number of s6-rc everytime I changed a service script was pretty silly in hindsight. Hopefully we won't have to go past -9. :P

Minor fixes:
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 16 January 2020, 17:02:29
All *-s6 packages install their files as 644 now. Next up is to make sure s6-linux-init works everywhere and compiles with the correct options. (mkinitcpio, dracut, liveiso and docker). At the moment, mkinicpio and the liveiso work. Docker doesn't work and dracut (probably) doesn't work but I haven't tested it yet.

Edit: Just confirmed it does actually work with dracut. Hurray.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 23 March 2020, 23:39:18
Finally got around to adding netdev/netmounting to s6-scripts. First, mark your partitions in fstab with the _netdev option. Then navigate to /etc/s6/sv/mount-net/dependencies and add a newline below "udev" with the name of the network daemon you use (dhcpcd, NetworkManager, etc.). After that, just run "sh /usr/share/libalpm/scripts/s6-rc-db-update-hook" as root to update your database and now any of your net mounts in your fstab should automatically mount on boot after your network is up.
Title: Re: [Tracker] s6 support
Post by: dnkl on 24 March 2020, 09:15:23
I tried this with dhcpcd. It doesn't work. It's a dependency "ready" issue; s6 starts mount-net as soon as dhcpcd has started, but before it has received an IP.

I haven't given this much thought yet, besides reading through the dhcpcd man page just to realize there's no --print-pid like option.
Title: Re: [Tracker] s6 support
Post by: phoenix_king_rus on 24 March 2020, 11:44:44
I tried this with dhcpcd. It doesn't work. It's a dependency "ready" issue; s6 starts mount-net as soon as dhcpcd has started, but before it has received an IP.

I haven't given this much thought yet, besides reading through the dhcpcd man page just to realize there's no --print-pid like option.
Code: [Select]
dhcpcd -b
backgrounds immediately, without this option it backgrounds once it got IP or timed out
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 24 March 2020, 13:45:06
I tried this with dhcpcd. It doesn't work. It's a dependency "ready" issue; s6 starts mount-net as soon as dhcpcd has started, but before it has received an IP.

I haven't given this much thought yet, besides reading through the dhcpcd man page just to realize there's no --print-pid like option.

Bummer, I was hoping mount would just hang until it receives a response as long as the network is up. I'll try to think of something more clever for this. There may be some filesystem-specific mount option you could use for this but something more generic would be nice.

Edit: Actually perhaps --printpidfile with clever shell redirects is what we need here.

Code: [Select]
dhcpcd -b
backgrounds immediately, without this option it backgrounds once it got IP or timed out

That sort of defeats the purpose of process supervision though. Not sure how it would fix it though? Wouldn't the mount still fail.
Title: Re: [Tracker] s6 support
Post by: phoenix_king_rus on 24 March 2020, 15:14:39
That sort of defeats the purpose of process supervision though. Not sure how it would fix it though? Wouldn't the mount still fail.
I just thought this flag is already used in s6
Title: Re: [Tracker] s6 support
Post by: dnkl on 27 March 2020, 12:09:02
I kind of gave up on this and just added this oneshot service that mount-net depends on instead of dhcpcd:

while true; do
    routes=$(ip route show)
    if [[ -n "${routes}" ]]; then
        break
    fi
    sleep 1
done


No, I'm not proud :(
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 27 March 2020, 16:08:13
I kind of gave up on this and just added this oneshot service that mount-net depends on instead of dhcpcd:

while true; do
    routes=$(ip route show)
    if [[ -n "${routes}" ]]; then
        break
    fi
    sleep 1
done


No, I'm not proud :(

At least it works! I briefly tried some things like writing the wpa_supplicant -P option directly to /dev/fd/3, but it didn't seem to work (as in the service didn't even start) for some reason. Maybe I did something wrong though.
Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 09 April 2020, 02:43:46
Minor note. I stopped being stupid realized that the purpose of opensysusers is to create system accounts so the newest version of s6 uses a s6log.conf file to create the s6log user for logging instead of the install script. Nothing changes for current s6 users however I also reworked the permissions handling so that the s6log group no longer needs any ownership over the /var/log directory. Instead, the individual logging directories are created with an install command that assigns the proper user/group/ownership (did you know you could assign group ownership with install? I didn't).

Anyways, you don't have to do anything, but for people on s6 already, feel free to set /var/log's ownership back to only root with a "chown root:root: /var/log" command after you get the next update.

Edit: Actually I think you might need to readd any users to the s6log group after the update since the opensysusers hook runs and does its thing.
Title: Re: [Tracker] s6 support
Post by: MilkCow on 23 November 2020, 16:35:02
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 set console=tty8 in /etc/default/grub. Seeing messages from cryptsetup-s6 on tty1 was nearly a deal breaker. I thought about moving to openrc because of this.

You better document console=ttyX somewhere on the artix linux wiki.



Title: Re: [Tracker] s6 support
Post by: Dudemanguy on 23 November 2020, 17:46:24
This thread is pretty old and should be closed since much has changed since then (ex. the default s6-rc invocations are no longer verbose and nearly every service has its own logger now). But yes, I can document that.