Il 24 ottobre 2026 è stata unita nel ramo principale di systemd la pull request #44324, aperta da Christian Brauner: da questo momento systemd può includere componenti scritti in Rust. Non è un dettaglio da addetti ai lavori del solo progetto: systemd è il PID 1 di praticamente tutte le distribuzioni Linux moderne, e qualsiasi cambiamento nella sua catena di build e nelle sue dipendenze finisce, prima o poi, sulla scrivania di chi gestisce server e immagini di sistema in produzione. La novità arriverà con systemd 263, la cui data di rilascio non è ancora stata annunciata ufficialmente ma è attesa entro dicembre 2026.

Cosa cambia davvero (e cosa no)

Il punto più importante per chi amministra sistemi Linux è capire i limiti precisi di questa modifica, perché il titolo “systemd adotta Rust” si presta facilmente a letture sbagliate. Non si tratta di una riscrittura: il codice C esistente resta C, punto. Il supporto Rust riguarda esclusivamente i nuovi programmi “leaf”, cioè binari autonomi che nessun altro componente del sistema usa come dipendenza. Restano in C, e ci resteranno:

• libsystemd, la libreria condivisa usata da innumerevoli altri processi e da software di terze parti;
• i moduli NSS (Name Service Switch);
• i moduli PAM;
• tutto il codice esistente, che non verrà portato in Rust nemmeno gradualmente.

La logica è prudenziale: un bug di linking o un problema di ABI in una libreria condivisa da centinaia di programmi avrebbe un impatto di gran lunga superiore a un singolo tool a sé stante. Scegliendo di partire dai “foglie” dell’albero delle dipendenze, i maintainer possono introdurre Rust senza rimettere in discussione la stabilità di tutto il resto.

Il primo caso pratico: systemd-keyring-setup

Il primo componente concreto che userà questo supporto è systemd-keyring-setup, oggetto della PR correlata #44114 (non ancora unita al momento della stesura, ma ora sbloccata dal merge di #44324). Si tratta di un programma che prepara i keyring del kernel all’avvio e registra i certificati X.509 usati da dm-verity, fs-verity e BPF: un ambito dove la sicurezza della memoria conta parecchio, ed è probabilmente anche per questo che è stato scelto come banco di prova.

Niente Cargo: la scelta sulla supply chain

Chi si aspettava l’arrivo dell’ecosistema Rust con il suo gestore di pacchetti resterà deluso, e non per caso. systemd non adotta Cargo. La build resta interamente su Meson, lo stesso strumento già in uso per il codice C, e il codice Rust è no_std: non usa la libreria standard, non comporta un allocatore globale implicito e si appoggia solo ai crate core e alloc (il crate libc è permesso dalla policy ma al momento non viene usato). Per la gestione della memoria, systemd-shared fornisce proprie implementazioni di Box e Vec che, in caso di esaurimento della memoria, restituiscono un errore gestibile invece di terminare il processo con un abort, replicando lo stile di gestione degli errori già adottato nel codice C del progetto.

La ragione dichiarata è la supply chain: un progetto che fa da PID 1 e che interviene nel processo di boot non vuole dipendere da un albero di crate esterni che non controlla direttamente. Niente crate di terze parti, quindi, almeno per ora: solo quello che offre la libreria core del linguaggio.

Come funziona l’integrazione lato build

Dal punto di vista di chi compila systemd da sorgente o mantiene un package per una distribuzione, il comportamento è pensato per essere il più trasparente possibile. L’opzione Meson che controlla tutto è -Drust=, con tre valori possibili:

# Rust abilitato solo se il toolchain è disponibile (default)
meson setup build -Drust=auto

# Rust obbligatorio: la configurazione fallisce se manca il toolchain
meson setup build -Drust=enabled

# Rust disabilitato esplicitamente
meson setup build -Drust=disabled

Con il valore auto, se sulla macchina non è installato un toolchain Rust la build procede comunque, semplicemente senza i componenti che lo richiedono. È una scelta importante per non costringere ogni sistema di build esistente a installare da un giorno all’altro una toolchain aggiuntiva. Attenzione però a un dettaglio poco intuitivo: se la versione di Meson installata è precedente alla 1.4.0, l’opzione auto si disattiva automaticamente, anche se rustc e bindgen sono presenti e funzionanti.

Chi invece vuole (o deve) compilare con il supporto Rust attivo ha bisogno di:

• rustc versione 1.85 o superiore;
• bindgen versione 0.71.1 o superiore — da notare che la 0.72.0 è esplicitamente respinta perché genera codice che non compila, e che una combinazione di bindgen precedente alla 0.72.1 con libclang 22 o successivo disabilita automaticamente il supporto;
• Meson versione 1.4.0 o superiore.

Da segnalare anche che la cross-compilazione non è ancora supportata in questa prima iterazione, un limite di cui tenere conto chi costruisce immagini per architetture diverse da quella dell’host di build.

Linking e dimensioni dei binari

Il collegamento tra i due mondi avviene esclusivamente tramite linkage C: i programmi scritti in Rust si collegano dinamicamente a libsystemd-shared esattamente come farebbe un binario C, mentre gli eventuali crate Rust vengono compilati staticamente all’interno del singolo programma che li usa. Dal punto di vista di chi lancia il comando, non cambia nulla: secondo quanto riportato dagli stessi autori, i binari Rust si comportano in modo identico a quelli C anche su dettagli come l’output di --help e il parsing degli argomenti da riga di comando — un requisito di compatibilità non banale per uno strumento di sistema.

Sul fronte dimensionale, il costo di questa impostazione “senza libreria standard” è contenuto ma non nullo: il programma di test test-cli-rust, compilato con LTO e stripped, pesa circa 32 KB contro i 20 KB del suo equivalente in C. Un overhead del 60% su un singolo binario minuscolo che, sui numeri assoluti in gioco per un sistema Linux moderno, è del tutto trascurabile.

Il contesto: un approccio deliberatamente prudente

systemd non è il primo progetto di base a muoversi in questa direzione: il kernel Linux integra già driver scritti in Rust da diverse release, e Ubuntu 26.10 ha completato il passaggio dei coreutils di sistema a implementazioni Rust. Rispetto a questi precedenti, l’approccio scelto dai maintainer di systemd è volutamente più conservativo: nessuna riscrittura, nessun obbligo di installare una toolchain aggiuntiva per chi non abilita le funzionalità che la richiedono, un’unica catena di build gestita da Meson. Per le distribuzioni che già compilano con --auto-features=enabled — tra queste, secondo la discussione sulla PR, Arch Linux e il build service di openSUSE — il requisito di avere rustc e bindgen disponibili (o di passare esplicitamente a -Drust=disabled) diventa invece immediato con l’aggiornamento a systemd 263.

Cosa monitorare da qui in avanti

Per chi gestisce infrastrutture Linux, i punti da tenere d’occhio in vista del rilascio di systemd 263 sono essenzialmente tre: l’eventuale merge di systemd-keyring-setup come primo componente Rust realmente distribuito, l’aggiornamento degli script di build e CI interni nel caso si compili systemd da sorgente (verificando le versioni minime di rustc, bindgen e Meson), e il comportamento dei propri package manager di riferimento rispetto alla nuova dipendenza opzionale. Nessuna azione è urgente oggi, ma è il tipo di cambiamento infrastrutturale che vale la pena di aver già mappato prima che arrivi con il prossimo aggiornamento di sistema.

Fonte: 4sysops, con dettagli tecnici dalla pull request #44324 su GitHub.