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:
# 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:
# s6-rc -u change default
Of course, you can also individual start services in the same way. So for example:
# 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:
# s6-rc -u change service
To bring down a service/bundle:
# s6-rc -d change service
To list all available services:
# s6-rc -d list
To generate a new database:
# s6-rc-compile /destdir /sourcedir
To update the database:
# s6-rc-update /path/to/compiled-database
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.
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)
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.
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.
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.
Artix
| Arch
|
system | core |
world | extra |
galaxy | community |
lib32 | multilib |
gremlins | testing |
goblins | staging |
galaxy-gremlins | community-testing |
lib32-gremlins | multilib-testing |
galaxy-goblins | community-staging |
lib32-goblins | multilib-staging |
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.
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).
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
Thanks for keeping the improvements coming!
Nit: why are all the files executable?
Please pardon my s6-ignorance, is it executed before or after / gets mounted rw?
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.
So, /etc/rc.local overrides /etc/s6/sv/rc-local?
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.
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.
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.
New versions of some s6 stuff pushed into system. Here's some brief changes/fixes.
- Your command in /etc/s6/rc.local can fail now without affecting other services. Previously, it returned an error code which then goofed everything else in the boot bundle up.
- There is now a log bundle that executes before boot (executed in /etc/s6/current/scripts/runlevel). The primary purpose of this is to ensure that logging is setup up as early as possible to catch those logs. Syslog-ng-s6 was changed so that it adds itself to this bundle. So if you had this package before, you need need to remove it with pacman and then install it again (so the install script triggers). This lets you get all of the early logs. Any other daemon that does syslog stuff could also be added here. I'm aware of s6-log, but I honestly haven't looked into (project down the road I guess).
- Similarly, cryptsetup-s6 and lvm2-s6 were also changed so their dependency chain executes correctly (udev -> crytsetup/lvm -> mount-filesystems). So if you had these services before, you should uninstall them with pacman and then install them again (install script reasons).
- s6-rc stuff installs with 644 now. On the to-do list is to do this with the other *-s6 packages since we don't need 755 for those either.
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:
- getty now waits on hostname being up. It was possible for a getty to start before the hostname was set meaning you'd get the default "artixlinux" hostname.
- /etc/s6/rc.local and /etc/s6/s6.conf are properly backed up in the PKGBUILD now (so your local changes don't silently get overwritten). Sorry for forgetting to do this earlier.
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.
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.
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.
dhcpcd -b
backgrounds immediately, without this option it backgrounds once it got IP or timed out
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.
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
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.
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.
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.
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.