BikyAlex
commented
5 months ago With the above examples out of the way, I think the easiest method would be to have dependencies.d propagate on a bundle. But if you know of a better way of doing it that already exists, I'm open to ideas.
Now, some background, which you can skip, as I finished all the technical review above. I'd still appreciate you (anyone) reading.
I'm trying to work on migrating systems to s6-linux-init and s6-rc and I wish to share that with the world, but for right now, this missing feature above is stopping me from doing a decent job of ensuring everything respects the dependency order.
How I've got things currently set up, all services are split in "runlevels" with a bundle for each runlevel. When booting, s6-linux-init just calls s6-rc -up change default ("$rl"). So I made a bundle called default and slapped all "runlevel bundles" inside the "default bundle." This results in all services "enabled" (i.e. added to the main bundles) to get started, but because the atomic services don't each have dependencies on the lower runlevel, they all start at the same time and in a wrong order.
I found out the hard way that things like sshd, chronyd and dhcpcd are trying to start before even dev, sys, proc and root are mounted. They're all in the bundle multi-user-target, which contains dependencies.d, but a "s6-rc-db -u dependencies sshd" shows that the only dependency this has it s6rc-fdholder. Obviously, I didn't know that bundles don't support dependencies. Sounded intuitive, but the manual clearly shows that's not the case.
I also want to take a moment to appreciate the good work you're doing here and thank you very much for your effort. You're an unsung hero.
skarnet
The s6-rc-compile seems to be missing / not take into account dependencies created on a type=bundle service.
The documentation doesn't mention it, so I thought it might be a missed entry, given that "flag-essential" on a bundle will be propagated on all services present in the bundles content.d folder. https://skarnet.org/software/s6-rc/s6-rc-compile.html
If you make a dependencies.d inside of a folder that has a type=bundle and add files with the names of services in it, just like you'd do with atomic services, this dependency is currently just ignored and doesn't get propagated.
Is there a way to globally define a common dependency on a whole group? I'd like to avoid having to individually go through each atomic service in a bundle and adding the dependencies.d directory for all of them.
As a few examples (yes, I know you can just "s6-mount -a" in a single service, this is just an example):
Another one:
Imagine I had more services, none of them requiring much dependencies (if any), just making sure they are in the proper "runlevel" (for lack of a better term). These would be getting included in their respective bundles, but all of them would have a "common ancestor" which can either be a bundle or a service.
When setting up serialized dependencies, it's easy, as you only need to add the immediate parent and in very rare cases a bit more than 1 dependency. But when launching a massive amount of services in parallel, that's where it gets annoying to set up dependencies (particularly if the atomic services don't even require dependencies at all, other than early startup things like udev, fs mounting and networking).
As an example of that, setting up an s6-rc service for each virtual machine I'm running would imply parent dependencies: networking (oneshot or longrun) -> iscsid (longrun) -> iscsi-login-logout (oneshot) -> vm1, vm2, vm3 etc. (longrun). But for all the VMs, the dependency has to be the iscsi-login-logout service, otherwise the VMs won't start (no attached disks). And let's say I put in the effort at first to write the dependencies.d/iscsi-login-logout at first for 300 VMs. Then something changes (say I move everything to local volumes instead of iscsi), so now I need to change 300 VMs' dependencies to something else (idk, making sure a particular disk is mounted and not in a failed state, say mount-vmdir, or zpool-import-vm-pool).
If I knew ahead of time that changes are inevitable, I'd have probably played it smart and made a bundle "vm-requirements" and added iscsi-login-logout to it and inside 300 VMs dependencies.d, I'd only have vm-requirements bundle. That'd make it trivial to just change the contents.d of the bundle from iscsi-login-logout to mount-vmdir or zpool-import-vm-pool. But I'd still have had to put in the time to write 300 dependencies.d/vm-requirements (assuming I didn't script it, which is probably what I'll do for now).