Ändern müssen zunächst nur diejenigen etwas, die systemd selbst bauen oder paketieren. Christian Brauner hat am 24. Oktober 2026 im Pull Request #44324 die Unterstützung für Programme in Rust gemergt, und zwar ausschließlich für neue Leaf-Komponenten. Rust ist optional und wird über die Meson-Option -Drust= gesteuert, Standardwert ist auto. Nötig sind rustc ab 1.85, bindgen ab 0.71.1 und Meson ab 1.4.0. Bestehender C-Code wird nicht portiert.
Wer fertige Pakete seiner Distribution installiert, bekommt von der Änderung im Build zunächst nichts mit. Für Build-Server, Container-Images mit eigenem systemd-Build und Paketbetreuende gilt dagegen: Die Toolchain-Anforderungen und das Verhalten von auto sollten vor dem nächsten Release-Zyklus bekannt sein. Dass sich daraus später mehr ergibt, hängt von weiteren Schritten im Projekt ab.
Gemergt ist ein Stack aus vier Änderungen, ein Programm steht noch aus
Der Pull Request #44324 trägt den Titel „rust: support programs written in Rust“ und stammt von Christian Brauner. Er ist Teil eines Stacks aus vier zusammengehörigen Änderungen. Ein solcher Stack zerlegt eine größere Neuerung in aufeinander aufbauende Pull Requests, die einzeln geprüft und gemergt werden können. Hier sind es #44323 mit C-Helfern, #44324 mit der eigentlichen Rust-Unterstützung, #44325 mit einem Wrapper und #44114 mit dem ersten Programm.
Gemergt sind nach dem Stand im Pull Request #44323 und #44324. Das erste geplante Rust-Programm, systemd-keyring-setup, steckt in #44114 und ist laut Pull Request noch offen. Damit existiert die Infrastruktur im Hauptzweig, ein ausgeliefertes Rust-Programm gibt es aber noch nicht. Wer den Build prüft, findet also vorerst eine Testkomponente und keine Funktion, die Nutzende bemerken könnten.
Was „Leaf-Komponente“ bedeutet
Der Begriff beschreibt Programme am Rand des Abhängigkeitsgraphen, also Blätter eines Baums. Andere Teile von systemd hängen von ihnen nicht ab. Das Projekt hat dafür zwei Regeln festgelegt: Rust darf nur für neue Komponenten verwendet werden, und nur für solche, von denen keine andere Komponente abhängt. Bestehende C-Programme werden nicht in Rust neu geschrieben.
Für den Betrieb hat diese Eingrenzung eine konkrete Folge. Fällt ein solches Programm aus oder fehlt es, bleibt der Kern aus PID 1, journald, udev und den Bibliotheken davon unberührt, weil keine seiner Funktionen daran hängt. Das ist eine dm-Einordnung aus der Regel „nichts, wovon andere abhängen“, keine Aussage aus dem Pull Request über Ausfallverhalten.
Für die Verbindung zwischen beiden Sprachen sorgen zwei weitere Teile des Stacks: #44323 liefert einen C-Helfer, der bereits gemergt ist, und #44325 ergänzt einen Wrapper. Beide sollen Rust-Programme an vorhandenen C-Code anbinden.
Wie Brauner die Entscheidung beschreibt
Auf Mastodon schrieb Brauner am 24. Oktober, nach langer Debatte habe man den Schritt getan: „After a long debate we finally pulled the trigger“. Die Rust-Binaries seien nur marginal größer als C-Binaries, es gebe kein Cargo, und sie verhielten sich wie C-Binaries.
Wie der Rust-Build ohne Cargo und fast ohne Crates aufgebaut ist
Gebaut wird ausschließlich mit Meson, dem Build-System, das systemd ohnehin verwendet. Cargo, der übliche Paketmanager und Build-Treiber der Rust-Welt, kommt nicht zum Einsatz. Das hat für Paketierende einen praktischen Vorteil: Es müssen keine Crates aus dem Netz nachgeladen oder in Vendor-Verzeichnissen gepflegt werden. Der Build bleibt ein Meson-Build, der auf den Rust-Compiler rustc zugreift.
Nur core, alloc und libc, ohne Standardbibliothek
Ein Crate ist in Rust eine Compilation-Einheit beziehungsweise ein Paket. Erlaubt sind nur die Crates core, alloc und libc. Der Code läuft als no_std, nutzt also nicht die Rust-Standardbibliothek std, sondern nur deren Kern. Dazu gehören Grunddatentypen und Sprachfunktionen ohne Betriebssystemanbindung. Die Anbindung ans System übernimmt die libc.
Das Crate alloc würde dynamische Datenstrukturen wie Box und Vec liefern, benötigt dafür aber einen globalen Allokator, der festlegt, woher Speicher kommt. Laut Pull Request wird alloc nicht genutzt. Stattdessen bringt systemd_shared ein eigenes Box und Vec mit, die ohne globalen Allokator auskommen. Dahinter steht dm-Einordnung zufolge ein naheliegender Grund: Speicherverwaltung bleibt damit in dem Rahmen, den systemd auch in C verwendet, und die Rust-Programme bringen keine eigene Allokator-Entscheidung mit.
C-Linkage, bindgen und die Frage, was statisch gelinkt wird
Die Verbindung zwischen Rust und dem vorhandenen C-Code läuft über C-Linkage. Das heißt, Rust-Code ruft C-Funktionen über die übliche C-Schnittstelle auf und umgekehrt. Die dafür nötigen Deklarationen erzeugt bindgen, ein Werkzeug, das aus C-Headern Rust-Bindings generiert. Deshalb steht bindgen in der Liste der Voraussetzungen, und zwar ab Version 0.71.1.
Beim Linken lohnt Genauigkeit. Die Rust-Programme linken libsystemd-shared dynamisch, genau wie die C-Programme. Statisch in die Programme eingebunden werden nur die Rust-Crates. Pauschal „statisch gelinktes Rust“ trifft die Lage also nicht. Für Admins heißt das: Die gemeinsame Bibliothek bleibt eine Laufzeitabhängigkeit wie bisher, und eine Rust-Laufzeitumgebung wird im Pull Request nicht als zusätzliche Abhängigkeit erwähnt.
Größenvergleich: 32 KB gegen 20 KB
Für das Testprogramm test-cli-rust nennt der Pull Request nach dem Strippen, also dem Entfernen von Debug-Symbolen, 32 KB bei Link-Time-Optimization (LTO). LTO optimiert über Compile-Einheiten hinweg beim Linken. Das C-Pendant kommt auf 20 KB.
dm-Rechnung: 32 KB minus 20 KB ergibt 12 KB Differenz. Bezogen auf die 20 KB des C-Programms sind das 12 ÷ 20 = 0,6, also 60 Prozent mehr. In absoluten Zahlen ist das winzig, in Prozent wirkt es groß, weil das Testprogramm sehr klein ist. Zu größeren Programmen sagt der Pull Request nichts, deshalb taugt der Wert nur als Hinweis auf die Größenordnung. Brauner spricht auf Mastodon von „only marginally larger“.
Was Distributionen und Paketierende bei Toolchain und Build beachten
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptSystem administrator with a laptop sitting on a server rack shelf, building software packages, abstract code blocks on screen, rust-orange accent light. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.Die Mindeststände sind kein Zufall. Meson 1.4.0 ist laut Pull Request der Stand, den Debian 13 ausliefert. Damit orientiert sich das Projekt an einer verbreiteten stabilen Distribution und setzt die Hürde nicht höher, als es für deren Build-Umgebungen nötig wäre. Wer auf älteren Basissystemen baut, etwa in langlebigen Build-Containern, sollte die Versionen von Meson, rustc und bindgen prüfen.
Was -Drust=auto tut
Meson kennt für Features drei Zustände: enabled erzwingt die Funktion, disabled schaltet sie ab, auto aktiviert sie, wenn die Voraussetzungen erfüllt sind. Bei systemd ist -Drust=auto der Standard. Das Verhalten bei älterem Meson ist im Pull Request beschrieben: Dort schaltet sich auto ab, der Build läuft ohne Rust durch. Ein zu altes Meson allein bricht den Standardbuild also nicht.
Wo Builds scheitern
Kritischer ist --auto-features=enabled. Diese Meson-Option setzt alle Features im Zustand auto auf enabled. Dann verlangt Meson Rust zwingend, und fehlen rustc oder bindgen, bricht der Build ab. Im Pull Request sind das konkret die Builds von Arch und openSUSE im Open Build Service (OBS), dem Build-Dienst von openSUSE, die ohne Rust-Werkzeuge scheitern.
Zwei Wege führen aus der Lage. Entweder wird Rust mit -Drust=disabled abgeschaltet, oder die Build-Abhängigkeiten rustc und bindgen werden in der Paketdefinition ergänzt. Welche der beiden Varianten einzelne Distributionen wählen, sagt der Pull Request nicht. Auch Aussagen darüber, welche Distributionen später Rust-Komponenten ausliefern, enthält er nicht.
Einordnung für den Betrieb
Als dm-Einordnung ergibt sich eine knappe Prüfliste für eigene Builds: Wird --auto-features=enabled gesetzt, braucht die Umgebung künftig rustc und bindgen oder eine ausdrückliche Abschaltung per -Drust=disabled. Ohne dieses Flag bleibt auto bei zu altem Meson stumm, was einen Build ohne Fehlermeldung, aber ohne Rust bedeutet. Wer sich darauf verlässt, dass später ausgelieferte Rust-Programme im Paket enthalten sind, sollte die Build-Logs auf den Status der Rust-Option prüfen.
Wer ohnehin Plattformwechsel plant, etwa nach den Änderungen in Linux 7.3 für Admins oder bei Ubuntu 26.10 mit Kernel-Release-Candidate, kann die Toolchain-Mindeststände in dieselbe Prüfung aufnehmen. Der Aufwand ist gering, weil sich die Anforderungen auf drei Werkzeuge beschränken.
Reine Anwendende ohne eigenen Build betrifft die Änderung nach dem Pull Request nicht. Eine Laufzeitabhängigkeit von Rust für Endnutzende erwähnt Brauner nicht, und die Programme verhalten sich laut seinen Angaben wie C-Binaries.
Was LWN zum Release-Zeitpunkt erwartet und was noch fehlt
Im Pull Request steht kein Releasedatum. Eine Einschätzung liefert LWN in einem Beitrag vom 26. Oktober 2026: Es erscheine wahrscheinlich, dass die Arbeit im systemd-Release v263 landet, das im Dezember erwartet wird. Im englischen Original heißt es, es „seems likely“, dass dies geschieht. Das ist eine Einschätzung der LWN-Redaktion, keine Zusage des systemd-Projekts und kein Termin.
Was zwischen Merge und Release liegt
Ein Merge im Hauptzweig bedeutet nicht, dass die Funktion in der nächsten Version enthalten sein muss oder dass dort bereits ein Rust-Programm ausgeliefert wird. Das erste Programm, systemd-keyring-setup, ist als #44114 weiterhin offen. Solange es nicht gemergt ist, enthält der Hauptzweig die Möglichkeit, Rust-Programme zu bauen, aber kein produktives Rust-Programm.
Wer systemd selbst baut, sollte daher unterscheiden: Die Build-Option -Drust= ist im Hauptzweig seit dem Merge vorhanden. Ob eine Release-Version sie enthält, entscheidet erst der Release-Prozess. Für Builds aus Release-Tarballs gilt die LWN-Einschätzung zu v263 als Orientierung, nicht als Planungsgrundlage.
Der Blocker: dynamische Bibliotheken
LWN beschreibt außerdem, warum der Einsatz von Rust im Kern von systemd vorerst offen bleibt. Das Projekt wünsche Rust auch dort, es gebe aber „several blockers in Rust’s support for dynamic libraries“. Das passt zur Architektur: Die systemd-Programme teilen sich libsystemd-shared als dynamische Bibliothek. Eine Rust-Komponente im Kern müsste in dieses dynamische Gefüge eingebunden werden, und genau dort sieht LWN Hindernisse bei der Rust-Unterstützung.
Die Leaf-Regel, nur neue Programme, nichts, wovon andere abhängen, umgeht diese Hürde. Leaf-Programme linken libsystemd-shared als normale Bibliothek per C-Linkage und bringen ihre Rust-Crates statisch mit. Dazu braucht es keine dynamische Rust-Bibliothek. Das ist eine dm-Einordnung aus den beiden Angaben: Der gewählte Zuschnitt vermeidet gerade das Problem, das LWN für den Kern nennt.
dm-Einordnung: Die Zeit bis zu einem Release lässt sich für Vergleichsbuilds nutzen. Paketierende können den Hauptzweig einmal mit -Drust=enabled und einmal mit -Drust=disabled bauen und festhalten, wo die beiden Läufe auseinandergehen. Hilfreich ist es, für jeden Lauf die verwendeten Stände von rustc, bindgen und Meson zu notieren. So wird erkennbar, ob ein Fehler an der Toolchain oder an der Konfiguration liegt. Fehlende Build-Abhängigkeiten fallen dann früh auf, nicht erst kurz vor einer Veröffentlichung.
dm-Einordnung: Wer eigene Images aus dem Hauptzweig baut, bekommt Rust-Programme womöglich schon mit, sobald die Voraussetzungen erfüllt sind. Ein Release-Tarball friert dagegen einen festen Stand ein. Admins mit eigenen Images sollten deshalb festlegen, aus welchem der beiden Stände ihre Builds stammen, denn davon hängt ab, wann Rust-Komponenten im Image landen.
