Along with new functionality, systemd is broadening its distro support even further, which will surely delight members of the wider Linux community.
Systemd v259-rc1 is the first preview release of what will be the next version of the most widely used system and service manager in the Linux world. It is also, of course, the most controversial, and some of the changes in this version further widen systemd's scope – which we suspect will provoke some push-back, but probably won't slow down its adoption or growth.
For some readers, the last entry in the NEWS file could be seen as the most significant part:
Incomplete support for musl libc is now available
It does, however, come with significant functional restrictions:
Note that systemd compiled with musl has various limitations: since NSS or equivalent functionality is not available, nss-systemd, nss-resolve, DynamicUser=, systemd-homed, systemd-userdbd, the foreign UID ID, unprivileged systemd-nspawn, systemd-nsresourced, and so on will not work. […] Caveat emptor.
What this means is that it's now possible to compile and run systemd on Linux distributions that are not based on the GNU version of the C standard library, glibc. In addition to glibc, there is now preliminary support for the main alternative libc of the Linux world, musl, as used in a number of lightweight distros such as Alpine Linux, Adélie Linux, and Void Linux, which, despite The Register's coverage of its maintainer problems in 2018, is still trundling along happily.
The reason that the functional restrictions might not matter too much is that the driving force behind this change is that postmarketOS, a project to offer a FOSS lifeline to smartphones no longer supported by their vendors, which we looked at a few years ago, announced last year that it was switching to systemd to better support the fondleslab versions of GNOME and KDE Plasma. PostmarketOS is based on Alpine Linux, and Alpine is built around musl, so the postmarketOS developers submitted some code to allow systemd to compile against musl instead of glibc. Earlier this week, Red Hat's Zbigniew Jędrzejewski-Szmek merged it, commenting:
I'll go ahead and merge this. It all does seem fairly fragile, so I'm a bit worried that maintenance will be a problem.
We suspect that these guarded reservations are why the 259-rc1 NEWS file carefully says:
This support for musl is provided without a promise of continued support in future releases. We'll make the decision based on the amount of work required to maintain the compatibility layer in systemd, how many musl-specific bugs are reported, and feedback on the desirability of this effort provided by users and distributions.
To which Achill Gilgenast, an Alpine and Postmarket developer, replied:
FWIW We, speaking as postmarketOS, are very motivated to help with the maintainance [sic].
(Folks new to this internet lark may not know but "FWIW" means "for what it's worth.")
There are a bunch of other functional changes, as those watching the progress of systemd over the years might expect. Its out-of-memory killer, systemd-oomd, has been revised in several areas, and it now reports more tracking information, which should help with debugging. A few years back, this module acquired a reputation for being overly aggressive, so more instrumentation is good.
Multiple parts of the code have improved support for the Varlink inter-process communication protocol, which LWN examined some years ago. Varlink usage is one of the parts at the end of lead developer Lennart Poettering's "Fourteen years of systemd" FOSDEM talk, which he had to skip for reasons of time, but it seems to be happening.
The built-in user-space device management and GUID partition management modules have been improved in multiple areas, including re-reading partitions on the fly and naming LUKS encrypted partitions separately from unencrypted ones. (As we mentioned in the bootnote to our systemd 252 story, incorporating the formerly independent udev subsystem in 2012 allowed the systemd developers to increase its version number by 139. Really, this version will be the 120th release.)
The tool now supports configurable log levels, and the systemd journal is now automatically persistent by default. The run0 command, systemd's replacement for sudo, which we introduced with systemd 256 and was enhanced in 258, now can temporarily "empower" an unprivileged user and can invoke commands in a specified root directory.
Some of the other changes concern the systemd-boot alternative bootloader, which has only been adopted by a few distros that The Reg FOSS desk has seen so far – notably including Pop!_OS, with disastrous results for our test laptop in 2021. Most distros still use GRUB, which keeps the Linux kernel and initramfs in the Linux file system – typically in a /boot folder. Systemd-boot is different: it only works on UEFI, and it stores these files directly in the EFI System Partition. This, obviously, takes more space – and what nuked our testbed machine was trying to enlarge the ESP. As the Arch wiki documents, systemd-bootd also supports a second, supplementary partition called the XBOOTLDR partition, just for these files, in case the machine's ESP isn't big enough. This version of systemd tightens up the requirements of the XBOOTLDR partition: this must be formatted in a simple file system readable by the computer's firmware, not just by the Linux kernel. In other words, some variant of good old FAT.
Support for System V style init scripts continues to be deprecated, although total removal has been postponed until systemd 260.
As we pointed out last time, systemd 258 development overran a little and it arrived slightly late. With this RC arriving just four months later, it looks like the team has caught up somewhat, and it's likely systemd 259 will be in the next releases of both Ubuntu and Fedora in the northern hemisphere's spring. ®
Source: The register