2️⃣3️⃣ Here's the 23rd post highlighting key new features of the recently released v261 release of systemd. #systemd261 #systemd
systemd-sysext is a tool in systemd's toolset that allows overlaying disk images over /usr/ in order to extend the OS vendor tree with additional resources, extending the base functionality of the base OS image. It comes with a counterpart for /etc/ called systemd-confext.
The tools can drop in any file whatsoever ultimately, however so far they weren't great for…
…dropping one very crucial type of file for the OS: systemd's unit files. The reason for that is one of ordering: sysext/confext are applied at point in time at boot where the local file systems are already mounted (because the primary place where the sysext/confext images are placed is /var/), but unit files we really try to read much earlier, when systemd initializes, and then generate a single unified transaction from it.
Now you could make it work, because in the metadata of the…
…sysext/confext you can specify to trigger a service manage reload, and then use .upholds/ dependencies to schedule unit jobs. But it's ugly, because we generally want to avoid reloads in the regular start-up paths.
With v261 we have made one relevant change in this area: we'll now apply any confext/sysext we can already discover from initrd context *before* transitioning into the rootfs, so that they are available already during generation of the initial transaction of the service manager.
This should work on all systems that do not have /var/ split out. For all others, the new logic will be likely a NOP (i.e. no images discovered, hence none applied), but then the usual invocation we always had will catch up. Or in other words, if /var/ is split out it will be as it always was, but if it isn't we can now ship unit files really nicely in sysext/confext too. Yay!
(BTW, splitting out /var/ from the rootfs I wouldn't suggest people to do anyway. I'd always suggest splitting…
Lennart Poettering
Levitating