systemd 259: Key Changes and System Requirements

Informatec Digital » Resources » systemd 259: Key Changes and System Requirements

The release of systemd 259 as a stable version represents another twist in one of the most controversial and essential components of the Linux ecosystem. We're talking about the framework for initiating and managing services that already dominates most distributions, and this release further tightens the screws in terms of technical requirements, security, and abandonment of legacy technologies.

This update comes after several months of intensive work and focuses on three main areas: compatibility with new C libraries, enhanced security, and cleaning up legacy code (SysV scripts, TPM 1.2, iptables, etc.). It also introduces significant changes to privilege management with run0, memory handling with systemd-oomd, log storage, and the internal dependency model of libsystemd.

systemd 259 and experimental support for musl

One of the most talked-about features of this version is that systemd 259 incorporates, for the first time, partial support for the C standard library musl . This library is widely used in lightweight systems, minimalist containers, and embedded environments, where simplicity and reduced resource consumption compared to glibc are desired.

Support for musl is enabled by setting the Meson build system's "libc" option to "musl" . However, this integration is far from complete: musl does not implement the Name Service Switch (NSS) mechanism, which forces the disabling of several parts of systemd when compiling against this library.

Specifically, building systemd 259 with musl excludes key components such as nss-systemd, nss-resolve, systemd-homed, systemd-userdbd, and systemd-nsresourced . The DynamicUser option and the ability to run systemd-nspawn without privileges are also unavailable, which is especially relevant in container environments that rely heavily on these capabilities.

The developers themselves acknowledge that they cannot guarantee long-term support . Its continuation will depend on the community's actual interest, the maturity of the additional layers that provide the functions musl lacks, and bug reports specific to this library. If demand is low or maintenance proves too complex, it wouldn't be surprising if this support were reviewed in future versions.

However, this opening to musl is important on a symbolic level: systemd had been criticized for years for its almost exclusive dependence on glibc , which made it unfriendly to alternative distributions and very minimalist scenarios. This step doesn't solve everything, but it breaks with that image of a system completely closed off to other C libraries.

run0 and the new privilege model: an alternative to sudo

Another major feature of systemd 259 is the utility run0, proposed as a modern and safer replacement for sudoThis tool was already built on systemd-run, but now it gains a key capability: the option --empower.

The new `--empower` argument allows you to start a session with elevated privileges without changing your UID to root . Instead of a traditional user switch, `run0` leverages kernel capabilities (such as `CAP_SYS_ADMIN`) to grant precisely the permissions needed to perform privileged actions, reducing the exposure of becoming root completely.

Furthermore, processes initiated with this approach are grouped into a logical "empower" group with access to a broad set of actions managed by Polkit . The idea is that the increase in privileges is granular and controlled, maintaining a stricter separation than that typically offered by traditional sudo, where access is often opened too wide.

This approach aligns with the trend of avoiding direct use of the root user whenever possible , a highly valued security principle. However, the true effectiveness of run0 still needs to be demonstrated in production: we'll have to see how it integrates with each distribution's policies, how its capabilities are configured in practice, and how well system administration adapts to the new workflow.

End of support for SysV init and legacy cleanup

systemd 259 also marks the beginning of the definitive end for System V-style service scripts . Compatibility with these classic mechanisms had been marked as "on its way out" for years, and now a clear timetable for their removal has been established.

This version announces that, looking ahead to the next major release, Historical components such as systemd-sysv-generator, systemd-rc-local-generator, and systemd-sysv-install will be removed.That is, the scripts in /etc/init.d/ They will no longer be taken into account by systemd, which closes a transition that has lasted for nearly a decade.

For administrators who still maintain custom services based on SysV scripts , this means getting down to work: all those scripts need to be inventoried and migrated to native systemd units (.service, .socket, etc.). Large distributions have already completed almost this entire transition, but in custom environments or older installations, some "relics" may still be running in the background.

This legacy cleanup process isn't limited to SysV. Recent versions of systemd have already been removing support for classic methods like `/forcefsck` and `/fastboot` , replacing them with kernel parameters and more modern credential mechanisms. With version 259, the direction is the same: less backward compatibility in exchange for a more maintainable and consistent codebase.

Minimum systemd requirements 259: kernel, libraries and environment

One of the changes that can have the greatest impact on older systems is the increase in the minimum software requirements to run systemd 259. This version no longer cares about very old hardware or stacks, and clearly pushes towards modern platforms.

Among the key requirements consolidated in systemd 259 are: a commitment to modern platforms

• Linux kernel 5.10 minimum (with a recommendation to go at least to 5.14).
• glibc 2.34 as a minimal version of the GNU standard library.
• Open SSL 3.0.0 as a mandatory basis for the supported encryption functions.
• util-linux 2.37 as a requirement for the basic utilities of the system.
• libxcrypt 4.4.0 for the management of cryptographic functions related to passwords.
• cryptsetup 2.4.0 and libseccomp 2.4.0 for volume encryption and system call filtering.
• Python 3.9.0 as a minimum dependency for auxiliary tools.
• Some notes also mention elfutils 0.177 as part of the updated set of dependencies.

This tightening means that very old systems or distributions clinging to kernel branches prior to 5.10 are automatically excluded from support for this version unless they update their underlying technology. In return, a more homogeneous ecosystem is achieved, with fewer special cases and compromise solutions.

For most general-purpose desktop and server distributions, these requirements shouldn't be a problem: modern LTS kernel branches already far exceed the 5.10 barrier , and the libraries mentioned are widely available. The biggest issues can arise in embedded systems, appliances, or very conservative installations that aren't updated frequently.

Enhanced security: TPM 2.0, encryption, and device restrictions

In the area of ​​security, systemd 259 accelerates its progress with several significant decisions. The most visible is that systemd-boot and systemd-stub definitively abandon support for TPM 1.2 , so that from now on only TPM 2.0 is considered the reference standard.

This change means that systems that relied on TPM 1.2 to manage secure boot policies or encryption keys will need to have their hardware upgraded (for example, by changing the motherboard) if they want to continue using these features with the newer versions of systemd-boot. Many Linux desktop users have TPM and Secure Boot disabled, so they may not even notice the change, but it could have an impact in corporate or high-security environments.

In previous releases, such as systemd 258, significant adjustments had already been made in this area: OpenSSL became the only encryption library supported by systemd-resolved and systemd-importd , leaving out alternatives like GnuTLS and libgcrypt. All of this points to a consolidation around a smaller, more controlled set of cryptographic tools.

Also in branch 258, stricter default access restrictions were introduced for tty/pts : nodes are created with permissions 0600 instead of 0620, preventing other users from writing to our terminals. This is another example of how systemd has been fine-tuning low-level details for some time, which, when combined, strengthen the overall security of the system.

libsystemd is more modular and dynamically loaded.

In pursuit of greater efficiency and a reduced dependency load, systemd 259 introduces profound changes to how libsystemd interacts with other system libraries . The goal is to prevent everything from being carried over from the start, instead loading it only when needed.

Specifically, libsystemd now uses dlopen() to dynamically load libraries such as libacl, libblkid, libseccomp, libselinux, and libmount . This means that these dependencies are not rigidly linked at compile time nor are they always loaded into memory: they are only activated when a specific function requires them.

This same mechanism with `dlopen()` also applies to integration with the Linux audit subsystem and PAM . In this way, systemd startup and normal operation can be lighter in environments that don't require all of these components simultaneously.

On the other hand, the functionality previously provided by the libcap library has been directly integrated into libsystemd . This eliminates another external dependency, simplifying the build chain and reducing potential points of failure or incompatibility.

In general terms, this approach provides better modularity and a smaller memory and disk footprint , especially in systems where fast boot times and a tightly packed set of services are desired.

Network and container changes: goodbye iptables, hello nftables

The networking and virtualization area also undergoes significant changes. Starting with systemd 259, systemd-networkd and systemd-nspawn no longer support the creation of NAT rules using iptables/libiptc . The only supported firewall backend becomes nftables.

This directly affects containers managed with systemd-nspawn that relied on NAT via iptables , as well as networks defined in systemd-networkd that used address translation rules with the classic backend. In tests with release candidates, silent failures in NAT functionality were observed until the entire configuration was migrated to nftables.

Beyond the translation of addresses, systemd-resolved gains the ability to use local hooks en /run/systemd/resolve.hook/These commands are executed every time a local name resolution query is performed. This opens the door to advanced DNS customizations and specific logic by the administrator.

In the field of image import and management, systemd-importd incorporates native logic for working with TAR files, relying on libarchive from the GNU tar utility. Furthermore, both systemd-importd and systemd-machined can now be run in user mode, managing system images placed in ~/.local/state/machines/.

To control these modes, the importctl utility adds the "--user" and "--system" options , allowing you to easily choose whether to operate in the user context or at the system level. This approach is useful for development and testing environments where you don't want to modify the machine's global configuration.

Persistent journaling by default and disk space management

Another change with practical impact is the modification of the default journal storage mode, the logging subsystem of systemd. Until now, the “automatic” behavior depended on the existence or not of the directory /var/log/journal.

With systemd 259, the default mode becomes "persistent ," regardless of whether the folder existed before. This means the journal will be permanently saved to disk by default, instead of being stored in volatile RAM.

This decision has pros and cons. On the one hand, it greatly simplifies troubleshooting , as logs survive reboots without requiring any special action from the administrator. On the other hand, in embedded systems, lightweight containers, or environments with very limited storage, it can result in a significant increase in disk usage.

In these scenarios, it will be more important than ever to adjust journal rotation and size policies , or even force a different storage mode if you want to avoid excessive wear (for example, in flash memories with limited write cycles).

systemd-oomd, OOM tracking and resource control

Memory management and "Out of Memory" scenarios also receive significant improvements. The systemd-oomd component, responsible for responding to insufficient memory situations , incorporates new properties to provide greater visibility.

Specifically, the OOMKills and ManagedOOMKills properties are now available for services , which record the number of processes terminated by the kernel or by systemd-oomd itself due to insufficient memory. This information can be accessed directly using systemd tools, facilitating subsequent incident analysis.

When a process gets out of control and starts "gobbling up" RAM to the point of jeopardizing the system , these metrics allow you to see at a glance which units have been affected, how many times the OOM mechanism has been triggered, and which components are causing the most memory pressure.

For administrators of high-load environments or systems with very tight resources, this greater ability to observe the OOM is especially useful, as it helps to identify poorly sized services or memory leaks that might previously go unnoticed.

Other notable improvements in systemd 259

In addition to the major changes mentioned above, systemd 259 comes loaded with numerous improvements and minor tweaks scattered throughout the ecosystem . Many are quite technical, but it's worth reviewing them because together they add up to a significant change.

Among the new features of the API, The Varlink protocol-based interface is being expanded to allow access to service configuration and execute IPC calls such as Reload() y Reexecute()Specific calls are also added to handle systemd-repart, systemd-resolved, and systemd-networkd functionalities.

In the area of ​​configuration and units, the ExecReloadPost option has been introduced , which allows commands to be launched immediately after a service's configuration is reloaded. Additionally, configuration files ending in ".ignore" are now automatically discarded , a simple trick for disabling files without having to delete or drastically rename them.

Temporary units gain ownership RootDirectoryFileDescriptor, which defines the file descriptor corresponding to the root directory, and a new option is added UserNamespacePath, which allows you to link a drive to a user namespace by specifying a path in /procIn systemd-nspawn, the directive appears NamespacePath in the section from the .nspawn files to indicate the network namespace to use.

Other components such as systemd-sysext and systemd-confext incorporate dedicated configuration files en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confEnvironment variables SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS They allow you to adjust the mounting options for Overlays.

In the world of udev, the option is added OPTIONS=»dump-json» to systemd-udevd To display the current state of an event in JSON format, the function net_id It generates predictable names for wireless interfaces on systems with DeviceTree and creates symbolic links. /dev/gpio/by-id/... for GPIO devices.

The user and account section is also being strengthened: The user database includes a UUID fieldThe userdbctl utility supports the "-uuid" option to search by this identifier, and homectl update It now supports "--recovery-key" to add recovery keys to existing accounts.

In systemd-homed, the options "--prompt-shell" and "--prompt-groups" are incorporated during the first boot using systemd-homed-firstboot.service, and in systemd-firstboot, "--prompt-keymap-auto" appears to ask for the keyboard map when using the local console on the first boot.

El The systemd-boot boot manager adds the ability to define the level of detail of the log with parameter log-level en loader.conf or with the SMBIOS field io.systemd.boot.loglevelIn addition, stricter requirements are being consolidated for partitions such as XBOOTLDR, which must now be in VFAT, in line with what is already required of the ESP in modern UEFI systems.

At the advanced networking level, systemd-networkd adds the EmitDomain and Domain options for the DHCP server and implements a controller that determines hostnames issued via DHCP using DNS resolution. Meanwhile, systemd-modules-load loads kernel modules in parallel , reducing boot times on systems with many drivers.

Finally, in the integrity section, systemd-integrity-setup adds support for HMAC-SHA256, PHMAC-SHA256 and PHMAC-SHA512 algorithms , expanding the range of cryptographic options available to protect system integrity.

With all these changes, systemd 259 solidifies its position as a highly technical, demanding, and clearly future-oriented version . It pushes users to abandon legacy technologies like SysV init, iptables, and TPM 1.2, strengthens security and resource control, improves internal modularity, and opens the door to new configurations with musl, albeit partially and conditionally. For end users on point-release distributions, many of these new features will go almost unnoticed; for administrators and projects that are constantly using the latest version, it's time to carefully review scripts, units, and hardware requirements before making the switch.