First release candidate of systemd 258 is here • The Register

Like it or not, systemd is the industry-standard init system these days. A new release is coming, and it’s a big one.

Version 257 of systemd came out last December, and since the team tends to release new versions twice a year, you could interpret that as meaning that version 258 is slightly overdue. The reason could be that this is a major release, with a substantial amount of new functionality. We don’t track these things especially closely, but The Reg FOSS desk has been reporting on new releases of the systemd suite since version 251 in early 2022, and off the cuff, we’d guess this is the biggest in that time.

Version 258-rc1, meaning release candidate 1, just appeared on GitHub, and the README file contains an impressive list of changes. Among the top ones are that it now needs at least Linux kernel 5.4, and support for cgroups version 1 is gone.

However, to get a feeling for what project lead Lennart Poettering feels are the significant changes, a better source could be his long series of posts on his Mastodon account, in which he explains the important functional changes over a whopping series of 32 threads. We went through them so that you don’t have to. That said, it’s long, complicated, and “Agent P” is a very smart chap, so it’s possible that we have misinterpreted some of them. A few of the comments we saw mentioned that certain posts sent people down research rabbit holes as they strove to understand, and they certainly have our sympathies. Some of the posts certainly describe a usage model that’s profoundly different from how this vulture uses Linux computers, and we may have misunderstood some of his points. Do please let us know if you spot any howlers.

So now, buckle up for a long and bumpy ride…

Post #1 tells us that there’s a new switch to the command to start a service: systemctl start -v $COMMAND results in verbose startup messages in the log from that service. Apparently, this was quite complicated to achieve.

Post #2 revolves around the somewhat controversial systemd-homed tool, which replaces the traditional Unix system of one home directory per user. Now, it supports multiple separate home directories for a user account, and provides a way to switch between them “by logging in specifying a user name of username%areaname at login time.” He also notes that “this is a systemd-homed feature, it’s not implemented for classic UNIX users.” Jumping forward, this tool also crops up in post #19, which explains that systemd 258 allows PAM authentication inside service units – so, for instance, a service can ask for passwords during startup. This works with systemd-homed for on-the-fly unlocking of encrypted home directories.

Post #3 says that “the query-routing logic in systemd-resolved got substantially upgraded: in addition to routing queries to the DNS config of each interface (and optionally one additional global one), there’s now the ability to define arbitrary numbers of additional ‘delegate zones.’ These are basically just combinations of DNS servers along with the domains to match queries with that shall be routed there.” Jumping ahead, post #13 introduces a new mechanism to be notified of DNS config changes.

DNS resolution is a common point of failure in 21st century computing systems. For reference, we recommend this handy reference site: Is it DNS?. We’ve already seen systemd-resolved causing people problems. It’s about to get more complicated.

Post #4 explains that today, many container systems use sub-UIDs and sub-GIDs. Agent P dislikes this, and now, he has a solution: “With v258 we are doing something about it: we set aside one fixed range of 64K host UIDs/GIDs that can now be used for container trees placed in regular directories. In other words: this allows container runtimes to place unpacked container trees in a user’s $HOME.” There are some new IPC calls for managing this, and the good news is that this is unprivileged.

Post #5 introduces new support for dynamic hostnames. “If the /etc/hostname file contains question mark characters, those are implicitly and automatically replaced by hex digits hashed from /etc/machine-id when processed.” Jumping ahead slightly, alongside this, post #8 explains how the ConditionHost= unit-file setting now can operate on the randomly-generated boot ID, and on the vendor ID, as well as on the hostname and /etc/machineid. We can see these being handy for those managing lots of boxes or VMs.

Post #6 introduces per-user quotas on space usage in the /tmp tree, so a single user account can’t use more than 80 percent. This closes off a potential route for DDoS attacks, and he links to an explanation of the rationale. Also trying to prevent system resource exhaustion, post #7 explains some new workload-management tooling to try to prevent overloading the system by starting more things at once than it can handle.

Post #9 explains that now, systemd exposes lots more meta-information about the currently executing process to terminal emulators via some new ANSI extensions. However, for now, this doesn’t include things invoked remotely over SSH. Improved terminal handling is clearly a point of interest: again leaping ahead slightly, post #24 has a historical lecture on the failures of Unix terminal handling, by way of leading up to some new features in version 258. This adds two new terminal capability settings: $COLORTERM and $NO_COLOR (based on an existing specification. Also, “we added support for limited auto-discovery of $TERM: as part of TTY initialization, systemd will now query the terminal for its terminfo database identifier, and then set $TERM to it.”

This does seem to be an area ripe for improvement, but we can’t help but feel that the idea of introducing more configuration options reminds us of something.

Post #10 explains that this release extends the formerly separate systemd-boot bootloader to understand URLs to UKI files over the network, thus embracing and extending UEFI’s existing HTTP boot support. Also regarding UKIs, post #15 explains that these all-in-one signed boot files can now include system firmware images too – again, mainly for more secure VMs.

New troubleshooting tools are always welcome, and post #11 introduces a new feature that allows branching to an interactive shell – and waiting for it to exit before continuing – at lots more points during startup. Similarly, and again leaping ahead a bit, post #30 explains a new systemd-analyze verb unit-shell, which opens a shell in that unit’s context, for testing and troubleshooting.

Post #12 explains a new method to tell systemd to perform a full factory reset at the next boot. We are willing to bet someone somewhere is going to regret trying that one out.

Post #14 explains a new mechanism by which systemd can now dynamically add entries to the systemd-boot startup menu, for troubleshooting and so on. This feature seems mainly for VMs.

Post #16 explains a mechanism that adds aliases for usernames, which fixes what Agent P sees as an issue where more than one UID points to a single account.

Post #17 explains that systemd now works with verity-protected block devices and Discoverable Disk Images (DDIs) to allow volumes to contain metadata about where they should be mounted. This does sound potentially handy to us – we’ve seen hard-to-fix failures caused by volumes being mounted in the wrong place – but this seems like a narrow implementation. However, adding metadata to the GPT partitioning scheme would be an epic undertaking.

Post #18 explains that version 258 extends the mechanisms for cryptographic signing of OS images, for example, so that they can be built on other machines. It calls out SUSE’s Open Build Service by name, but for now, this can’t build SUSE images, only ones using Particle OS – but we suspect that support for these mechanisms will be added to other distros in time.

The change described in post #20 allows mount options from more recent kernels, which older ones don’t understand, to be suppressed, so the volumes still mount when running on an older kernel release. On the one hand, that should make things more robust, but on the other hand, it could conceivably also introduce some very hard-to-troubleshoot failures.

Continuing the eternally popular theme of system introducing new modules and functions, post #21 describes a new service, systemd-userdb-load-credentials.service, which simplifies the process if you’re using userdb to handle accounts using drop-in JSON files. It only runs under those conditions, though. More userdb fun is introduced in post #28, which explains how this and the previous systemd release offer tools over and above traditional Unix specifications. Currently, POSIX just allows matching a particular user account. Systemd 257 added user account filtering and matching against criteria, such as the GECOS field; for instance, you can configure things for ranges of accounts, or for a set of accounts matching a pattern. In version 258, this functionality is exposed via an IPC call as well.

Systemd has been able to start and manage containers on its own for over a decade – The Register first mentioned the systemd-nspawn command back in 2014. It can also run full VMs using the analogous systemd-vmspawn command. In post #22, Agent P explains that he uses this a lot and so has added a parameter to expand the new VM’s filesystems. The new switch --grow-image= (or -G for short) does it for you, so you don’t need to manually adjust the size with truncate or fallocate. This is something we’ve never once felt the urge to do, but perhaps it will be good news for someone somewhere.

Also in VM management, post #31 explains that systemd VMs now show their VSOCK context identifier or CID on startup. This makes it easier to connect to instances without going across the network.

Post #23 explains that systemd-notify can now fork off background processes and wait for them to complete.

Returning to its container-management functionality, post #25 explains that while systemd-nspawn is starting a container, the keystrokes ^]^]^] will kill the container. Now in 258, there are two new commands as well: ^]^]r reboots the container, and ^]^]p powers it off. For this to work, though, you will need a compatible init inside the container.

Post #26 has an unusually cautious tone, as it explains that ExecStart= takes flags “denoted via special characters, such as @, -, :, +, and ! as the first character of the setting’s values. (Yes, this is a bit cryptic, we have to admit that).”

Now, it takes | as well. The pipe character means “we invoke the shell and pass the specified command via the”-c” parameter to it.” He notes that you could use this for passing scripts to the command, but that’s a bad plan. The idea is to let systemd’s new run0 command – its replacement for sudo – to pick up that account’s shell.

By post #27 things are starting to get arcane. The existing systemd-sysext tool lets you layer DDI images to build a custom /usr tree, which is handy in immutable setups where you can’t change it. In addition, systemd-confext does all this for /etc/ too. The objective is to provide tooling to manage configuration in immutable distros, without the need to modify their read-only filesystems. The layering concept will be immediately familiar to many sysadmins from Docker, as this is how container images are constructed.

The core function of systemd is to act as a service manager, and post #29 explains that the service manager now gets disk space management to go with the existing management of CPU, RAM, I/O and so on.

Finally, after post #17 talked about verity protection for block devices, post #32 discusses how the systemd-repart tool now supports file-level fs-verity checks in addition to the existing block-level dm-verity ones.

This is a lot to digest, and we boiled it down as much as we were able. We are sure that the many folks who don’t care for systemd will find plenty of fuel for their ire here. This version will also pose a challenge for distros such as the experimental GNU-free Chimera Linux, which aim to replicate some of the more advanced functionality of systemd. Possibly not too much, though, given how many of the new features involve containers and virtual machines. You can expect to see system 258 in the distros that will appear later this year, including Ubuntu 25.10 and Fedora 43, and we suspect that some of its functionality will become integral to tools such as the next Ubuntu LTS, 26.04 (or possibly 28.04), and also to RHEL 11. ®