systemd 260-rc1 Released: New 'mstack' Feature, System V Service Scripts No Longer Supported

The first release candidate of systemd 260 is now available for testing, marking a significant milestone in the evolution of the Linux init system. This release brings several notable changes, with the most impactful being the removal of System V service script support and the introduction of the new 'mstack' feature for OverlayFS management.

End of an Era: System V Scripts Removed

After years of deprecation warnings, systemd 260 finally drops support for System V service scripts. This change has been anticipated for some time, but its arrival marks the definitive end of the traditional SysVInit compatibility layer that has been part of systemd since its early days.

The removal means administrators must now rely exclusively on native systemd unit files for service management. While this transition has been ongoing for years, it represents a clean break that could affect older systems or distributions that still maintained SysVInit compatibility. Users running legacy scripts will need to convert them to systemd unit files before upgrading.

The New 'mstack' Feature

Perhaps the most intriguing addition in systemd 260 is the new 'mstack' feature, which provides a novel way to define and manage OverlayFS filesystems. The feature works by structuring the contents of a .mstack/ directory according to a specific specification, allowing for declarative OverlayFS configuration.

The systemd-mstack command line tool has been added to interact with this new capability. This tool enables users to create, modify, and manage overlay stacks through a straightforward directory-based interface rather than complex mount command sequences.

According to the development team, mstack is designed to simplify container and sandboxing workflows. The feature integrates with importd to support downloading OCI images, expanding systemd's containerization capabilities. This positions systemd as not just an init system but also a more comprehensive container management solution.

Technical Requirements and Compatibility

With systemd 260, the minimum supported Linux kernel version has been bumped from 5.4 to 5.10. However, for full functionality, the developers recommend at least Linux 5.14 or ideally Linux 6.6. This kernel requirement increase reflects systemd's growing reliance on newer kernel features and its decreasing need to maintain compatibility with older systems.

Enhanced System Identification

A new FANCY_NAME field has been introduced for os-release files. Similar to the existing PRETTY_NAME field but with expanded capabilities, FANCY_NAME can contain ANSI sequences including Unicode emojis. This field will be displayed by the systemd manager, systemd-hostnamed, and hostnamectl, allowing for more expressive system identification.

Network and Security Improvements

systemd-networkd now integrates with ModemManager via the "simple connect" protocol, improving cellular network support for systems that rely on mobile connectivity. This integration simplifies the configuration of cellular connections and provides better integration with systemd's network management framework.

systemd-repart gains basic integrity checks for encrypted volumes, enhancing the security of system partitioning operations. This addition provides verification that encrypted volumes haven't been tampered with during repartitioning operations.

Expanded User Capabilities

systemd-portabled now runs as a user service, allowing unprivileged users to run portable services on recent Linux kernels. This change democratizes access to portable service functionality, which was previously limited to system administrators.

Varlink Expansion

The release continues the trend of expanding Varlink usage throughout systemd. Varlink provides a modern, language-agnostic interface description format that simplifies integration with systemd components. The continued expansion suggests a long-term strategy to make systemd more accessible to developers working in various programming languages.

Testing and Migration

As this is a release candidate, administrators should test systemd 260-rc1 in non-production environments before considering deployment. The removal of System V script support means migration planning is essential for affected systems. The development team has published detailed release notes on GitHub for those wanting to explore the changes in depth.

The systemd 260 release represents both continuity and change - maintaining systemd's position as the dominant Linux init system while pushing forward with new capabilities that blur the lines between traditional init functionality and modern container management.