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

Re: [Tracker] s6 support

Reply #15 –
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

Re: [Tracker] s6 support

Reply #16 –
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.

Re: [Tracker] s6 support

Reply #17 –
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).

Re: [Tracker] s6 support

Reply #18 –
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.

Re: [Tracker] s6 support

Reply #19 –
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.

Re: [Tracker] s6 support

Reply #20 –
Thanks for keeping the improvements coming!

Nit: why are all the files executable?
 

Re: [Tracker] s6 support

Reply #21 –
Quote from: Dudemanguy – on
By default, it execute immediately on bootup
Please pardon my s6-ignorance, is it executed before or after / gets mounted rw?

Quote from: Dudemanguy – on
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.

Quote from: Dudemanguy – on
As a aside, /etc/rc.local will be executed instead if it exists.
So, /etc/rc.local overrides /etc/s6/sv/rc-local?

Re: [Tracker] s6 support

Reply #22 –
Quote from: dnkl – on
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.

Quote from: nous – on
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.

Re: [Tracker] s6 support

Reply #23 –
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.

Re: [Tracker] s6 support

Reply #24 –
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.

Re: [Tracker] s6 support

Reply #25 –
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.

Re: [Tracker] s6 support

Reply #26 –
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.

Re: [Tracker] s6 support

Reply #27 –
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.

Re: [Tracker] s6 support

Reply #28 –
Quote from: dnkl – on
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
ARMtix

Re: [Tracker] s6 support

Reply #29 –
Quote from: dnkl – on
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.

Quote from: phoenix_king_rus – on
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.