systemd Merges Optional Rust Support for New Standalone Programs, With Meson Only, No Standard Library and Core Libraries Staying in C for Now
systemd merged optional Rust support for new leaf programs on 2026-10-24: Meson not Cargo, no_std, core libraries stay C for now. It is in the 263 development branch; project pages disagree on binary sizes and Meson version.
Overview
The systemd project merged support for writing programs in Rust on 2026-10-24, according to the GitHub record of pull request #44324, titled “rust: support programs written in Rust” and authored by Christian Brauner (the merge is stamped 06:21:59 UTC; all GitHub times below are UTC). The support is optional and limited to new standalone programs. The Register reports that systemd 262 was released “about a month ago” and that systemd 263 is under construction, and the merged NEWS file lists the change under “CHANGES WITH 263 in spe”. In its own check of the project’s GitHub tags on 2026-11-09, the Herald found no tag beginning with v263, so the change is in the development branch and not in a tagged release. The Herald previously reported on the 262 release.
What was merged
The merged CODING_STYLE.md sets these rules for Rust:
- Rust “is only used for new leaf components, i.e. programs that nothing else in the tree depends on.” Existing C code is not ported “for now”, and
libsystemd-shared,libsystemd, the NSS and PAM modules and everything else other components depend on stay C. - The document states “Rust code is built with meson only. cargo is not used.”
- Only the
coreandlibccrates are permitted. The document listsstd,allocand any other crate as not permitted, so all Rust code is#![no_std]. - Rust code talks to the rest of systemd only through C linkage.
The Register summarises the scope this way: “this does not indicate the start of an effort to rewrite systemd in Rust. All it means is that new systemd modules can be written in Rust.”
For builders, the merged HACKING.md says Rust support is optional and requires rustc 1.85, bindgen 0.71.1 and meson 1.4.0 or newer. With the default -Drust=auto, support is turned off if the toolchain is missing or too old, while -Drust=enabled makes the build fail instead. Linuxiac notes that builds enabling all available features need the Rust compiler and bindgen or must disable Rust support to avoid build failures.
The first program and the compiler side
The first consumer is systemd-keyring-setup, which enrolls X.509 certificates into kernel keyrings at boot. Its pull request #44114 describes it as “the first program in systemd written in Rust” and was merged on 2026-10-27 at 09:27:22 UTC. Linuxiac’s October 24 report had said the implementation was still being developed separately.
On 2026-10-24, the day #44324 merged, a Rust compiler pull request was opened: rust-lang/rust #164855, “Stop mangling rust_eh_personality again for now”, by bjorn3. Its description says some projects define rust_eh_personality themselves because they use no_std. A comment by the author gives the motivation as a line in the systemd pull request’s diff. By the Herald’s own check, that diff anchor corresponds to src/rust/systemd-shared/panic.rs, and that file as merged defines a rust_eh_personality function. When a reviewer asked whether the revert was temporary, bjorn3 answered “Yeah, this would be temporary until a better solution is found.” The pull request was merged at 20:21:21 UTC the same day.
Reasons given on November 3
Phoronix, in an article dated November 4, says Brauner and Poettering wrote a blog post “on Tuesday”, which the Herald reads as 2026-11-03, and describes both as systemd lead developers who recently started the Amutable company. Linuxiac’s November 7 summary lists their reasons:
- The central libraries, including libsystemd-shared.so, remain in C because Rust lacks first-class shared library support and a stable ABI; otherwise Rust code would be duplicated across libraries and executables, in a project with more than 180 binaries.
- Cargo was rejected in favour of Meson alone, to avoid maintaining two build systems; security and supply-chain concerns about Cargo were also cited.
- Third-party crates are not ruled out, but the maintainers want more experience with the Rust ecosystem first.
- Established components will not be rewritten merely to change language, because replacing C with Rust does not automatically address security problems when the main attack surface is filesystem path handling rather than memory safety.
- Rust support will remain optional; the developers acknowledge Rust does not support every architecture systemd currently supports.
Phoronix quotes the post’s closing: “systemd would also like to see Rust adopted in core components and is willing to engage with the Rust community to make this a reality.”
Where the places disagree
Two figures differ between pages of the same project, and no cited source explains either, so the Herald reports both. First, binary size: the pull request description says “the stripped test-cli-rust binary is 32 KB with LTO against 20 KB for its C twin”, figures that Linuxiac repeated on October 24, while the merged HACKING.md says “test-cli-rust is 29 KB, 24 KB with -Db_lto=true, test-cli-c is 16 KB.” Second, the minimum Meson version: the pull request description, NEWS, HACKING.md and the build file check say 1.4.0, while the merged README says ”>= 1.8.0 is required to build programs written in Rust”.
What is not known
None of the cited sources gives a release date for systemd 263. The description of pull request #44324, opened on October 20, noted that Arch and openSUSE OBS builds failed because their packaging enables all auto features without pulling in rustc and bindgen; none of the cited sources says whether that has since been resolved.