systemd erlaubt künftig neue Programme in Rust
systemd hat am 24. Oktober die Unterstützung für Programme in Rust gemergt. Erlaubt sind nur neue, eigenständige Komponenten, gebaut mit Meson statt Cargo, ohne Standardbibliothek und externe Crates. Endnutzer merken davon vorerst nichts, Paketierer brauchen rustc, bindgen und Meson 1.4.
Das systemd-Projekt erlaubt ab sofort Programme, die in Rust geschrieben sind. Am 24. Oktober 2026 wurde der Pull Request 44324 von Christian Brauner mit dem Titel „rust: support programs written in Rust“ in den Hauptzweig übernommen. Die Änderung landet damit voraussichtlich in systemd 263. Rust ist dabei ausdrücklich auf neue, eigenständige Komponenten beschränkt, bestehender C-Code wird nicht umgeschrieben.
Relevant ist das vor allem für Distributionsbauer, Paketierer und Admins, die systemd selbst bauen. Wer systemd aus den Paketquellen seiner Distribution bezieht, merkt davon zunächst nichts. Handlungsbedarf besteht heute nicht. Paketierer sollten die neuen Build-Abhängigkeiten aber vor dem nächsten Release einplanen, weil sonst Builds scheitern können.
Was ist passiert?
Der Pull Request ist Teil einer Serie aus vier Teilen. Zuerst kamen C-Hilfsfunktionen (PR 44323), jetzt die eigentliche Rust-Unterstützung. Es folgen Rust-Wrapper für die gemeinsame Bibliothek libsystemd-shared (PR 44325) und als erstes echtes Rust-Programm systemd-keyring-setup (PR 44114). Dieses Werkzeug soll laut Phoronix beim Booten Schlüsselbunde einrichten und X.509-Zertifikate in die Kernel-Keyrings für dm-verity, fs-verity und BPF eintragen. Es ist noch nicht gemergt.
Die Regeln haben die Maintainer nach Angaben im Pull Request bei einem Hackfest in Berlin festgelegt:
- Rust nur für neue Endkomponenten, von denen keine anderen Teile abhängen.
- Kein Cargo, gebaut wird weiterhin ausschließlich mit Meson.
- Nur die Crates core, alloc und libc, der Code ist no_std, externe Crates sind nicht erlaubt.
- Nur C-Linkage: Rust-Programme binden libsystemd-shared dynamisch ein wie die C-Programme.
Die Anbindung an libsystemd-shared erzeugt bindgen beim Build aus denselben Headern. Darüber liegt eine eigene Crate, die die Konventionen der C-Programme nachbildet: Fehler über errno, Logging, Hilfe-Ausgabe und Optionsverarbeitung. Ein Test prüft Byte für Byte, dass ein Rust-Programm dieselbe Ausgabe liefert wie sein C-Gegenstück. Geheimnisse landen in einem Speichertyp, der beim Freigeben automatisch überschrieben wird.
Für wen ist das relevant?
Die Rust-Unterstützung ist optional und wird über die Meson-Option -Drust= gesteuert, Standard ist auto. Wer sie nutzen will, braucht rustc ab 1.85, bindgen ab 0.71.1 und Meson ab 1.4.0. Das entspricht laut Pull Request dem Stand von Debian 13. Auf älteren Meson-Versionen schaltet sich die Option selbst ab.
Einen Haken nennt der Pull Request selbst: Die Builds für Arch und openSUSE im Open Build Service schlugen fehl, weil deren Paketierung mit --auto-features=enabled baut und rustc sowie bindgen nicht als Abhängigkeit mitbringt. Solche Builds brauchen entweder -Drust=disabled oder beide Werkzeuge als Build-Abhängigkeit. Nicht betroffen sind Anwender, die fertige Pakete ihrer Distribution nutzen, und Server, auf denen systemd nur läuft und nicht gebaut wird.
Was ändert sich praktisch?
Für den Betrieb zunächst wenig. Bestehende Dienste, Unit-Dateien und Werkzeuge bleiben C-Programme. Rust-Programme sollen sich nach außen genauso verhalten wie die bisherigen Werkzeuge. Messbar ist ein Größenunterschied: Ein kleines Test-Kommandozeilenprogramm belegt gestrippt 32 KB gegenüber 20 KB für die C-Variante. Das ist nur ein Testprogramm und kein Maßstab für künftige Komponenten. Ob und wie stark Rust in systemd wächst, ist offen.
Was sollten Admins jetzt tun?
- Inventar prüfen: Mit
systemctl --versionden laufenden Stand erfassen und klären, ob irgendwo eigene systemd-Builds oder angepasste Pakete im Einsatz sind. - Paketierer und Betreiber eigener Builds sollten rustc ab 1.85, bindgen ab 0.71.1 und Meson ab 1.4.0 als Build-Abhängigkeit vorsehen oder bewusst
-Drust=disabledsetzen. - Build-Pipelines, die mit
--auto-features=enabledarbeiten, vor dem Wechsel auf systemd 263 testen. - Für Server mit Distributionspaketen genügt es, die Release Notes von systemd 263 abzuwarten.
Einordnung für Unternehmen
Für die meisten kleinen und mittleren Unternehmen ist das eine Richtungsentscheidung ohne unmittelbare Folgen. Die Entscheidung reiht sich in einen breiteren Trend ein, etwa den Umstieg von Ubuntu auf Rust-basierte Coreutils. Der vorsichtige Ansatz mit no_std, ohne Cargo und ohne externe Crates zielt auf eine kontrollierte Lieferkette und auf sichereren Umgang mit Speicher. Wer eigene Images oder Appliances mit selbst gebautem systemd pflegt, sollte die neue Toolchain früh in die Build-Umgebung aufnehmen.
Passende Anleitungen auf S-EDV
- systemd-Services erstellen und verwalten: Grundlagen zu Unit-Dateien und systemctl.
- Ubuntu schließt den Umstieg auf Rust-Coreutils ab: ein weiteres Beispiel für Rust in zentralen Linux-Werkzeugen.
