Systemd, the de facto standard init system on Linux, has just taken the first step to support Rust programs, in addition to the standard C.
Systemd was originally created as an init system, called by the kernel during startup, and responsible for launching and managing other services and processes. Systemd was created by Lennart Poettering and Kay Sievers while working for Red Hat, with the goal to modernize and improve how Linux initialization works.
Over the years, however, systemd has grown far beyond a simple init system and now manages many parts of a Linux system, as described on the project’s home page:
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.
systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic.
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
Rust Support
With a pull request merged on Oct. 24, the project now supports the Rust programming language.
This adds support for writing systemd programs in Rust. It replaces #43551 and reworks it along the lines the maintainers agreed on at the Berlin hackfest.
Much to many users’ likely relief, systemd will not be rewritten in Rust, but the language’s use will be reserved for new components.
- Rust is only used for new leaf components. Existing C code isn’t ported and nothing that other components depend on is written in Rust.
- No cargo. Everything is built with meson.
- Only the core, alloc and libc crates. Rust code is no_std and there are no other crates. The libc crate isn’t needed yet, the bindings generated from the tree’s own headers cover libc. And like the kernel we don’t use alloc either. Its collections abort when memory runs out. systemd_shared has its own Box and Vec instead, which work like the kernel’s: everything that allocates returns an error and there’s no global allocator.
- C linkage only. libsystemd-shared and the dlopen machinery stay as they are. A program written in Rust links libsystemd-shared dynamically just like the C programs do and declares its dlopen() dependencies in .note.dlopen. The Rust crates are linked statically into the programs using them.
Potential Controversy
Systemd has garnered its fair share of controversy over the years, especially as its scope and feature set continued to grow. Many users feel it violates the UNIX philosophy of a program or service doing one thing and doing it very well. Still others blame systemd for the growing separation between Linux and its BSD cousins, as the BSDs have not adopted systemd. Systemd is also accused of weakening the security of Linux by offering potential attackers a much broader attack surface because of its vast scope and reach.
Adding support for Rust is sure to add fuel to the fire for those who don’t like systemd. Many users and developers accuse Rust of being a meme language, the latest, greatest obsession that is often applied unilaterally to everything regardless of whether it brings actual benefit to a given scenario.
Even so, while it may be over-applied, Rust does offer real benefits, especially when it comes to memory safety and security. Given the important role systemd plays, supporting Rust is a move that makes sense and could well deliver significant value over the long term.