systemd: cos'è e perché è un problema per i sistemi Linux embedded

Da tempo si fronteggiano i sostenitori di systemd come strumento per l’inizializzazione di Linux e coloro che invece ne criticano le caratteristiche e l’approccio, preferendo soluzioni alternative.

Un sistema di init è responsabile dell’avvio dei servizi e delle applicazioni necessari per il funzionamento del sistema operativo. Nel caso di systemd, il meccanismo gestisce tutto ciò che è necessario dall’avvio del sistema fino al completamento della fase di avvio, sostituendo i tradizionali script di init con dei file in formato .service, molto più flessibili e personalizzabili.

systemd è nato nel 2010 per opera degli ingegneri Red Hat Lennart Poettering e Kay Sievers; è oggi adottato da molte delle principali distribuzioni GNU/Linux come Ubuntu, Fedora, Debian e Arch Linux.

Perché tante polemiche intorno a systemd?

systemd ha generato polemiche fin dalla sua introduzione nel mondo Linux, principalmente per il suo approccio all’init system, per le sue ambizioni di sostituire o inglobare vari componenti del sistema e per via delle varie implicazioni sul piano tecnico e “filosofico”.

Il sistema è stato concepito per essere un gestore completo per l’inizializzazione di GNU/Linux. Con il tempo è cresciuto a dismisura in termini di funzionalità: si pensi all’aggiunta della gestione dei log, alla pianificazione delle attività (cron), al supporto della rete, alla gestione degli utenti. Tante abilità integrate in systemd hanno portato a consumi di risorse molto più incisivi che in passato.

Secondo molti, l’approccio perseguito da systemd sarebbe contrario alla filosofia Linux secondo cui ciascun componente software dovrebbe limitarsi a fare una cosa sola, facendola per bene. D’altra parte se da un lato è vero che systemd è congegnato per utilizzare un design modulare, il progetto gestisce funzionalità che una volta erano prerogativa di singoli e specifici strumenti software.

Molte distribuzioni Linux, per vari motivi, sono passate a systemd come init system predefinito, creando una sorta di dipendenza indiretta. Alcuni programmi e componenti sono stati riscritti per funzionare con systemd, creando una catena di dipendenze che rende difficile adottare sistemi alternativi. Uno schema giudicato dai detrattori come una sorta di blocco, un legaccio (lock-in) che limiterebbe le libertà degli utenti e degli sviluppatori.

A questo proposito, i più critici puntano il dito contro Red Hat, acquisita da IBM nel 2019 per la cifra di 34 miliardi di dollari. Un componente cruciale come systemd sarebbe sotto il controllo di un’unica azienda.

I vantaggi di systemd

systemd rappresenta un’importante evoluzione nella gestione dei sistemi operativi Linux, introducendo una serie di vantaggi significativi rispetto ai tradizionali sistemi di init. Uno dei principali punti di forza di systemd è la sua capacità di velocizzare il processo di avvio del sistema. Grazie alla parallelizzazione dei servizi, systemd è in grado di avviare più componenti simultaneamente, riducendo notevolmente il tempo necessario per rendere operativo il sistema.

Il sistema di gestione delle dipendenze, inoltre, si assicura che ogni servizio venga avviato solo quando tutte le risorse necessarie sono disponibili, evitando così errori e migliorando l’affidabilità complessiva.

Un’altra innovazione chiave introdotta da systemd è il concetto di “unità“, file di configurazione che possono rappresentare servizi, mount point, dispositivi e altro. Essi rendono la configurazione del sistema più modulare e flessibile.

Ogni unità è gestita tramite un file specifico, come quelli con estensione .service per i servizi e .target per i gruppi di unità. Questa modularità permette agli amministratori di personalizzare e ottimizzare facilmente la gestione del sistema in base alle proprie esigenze.

Gestione dei log e dei servizi in esecuzione

systemd include anche un sistema di logging centralizzato noto come journald. Questo strumento raccoglie e gestisce i log in un formato binario, semplificando l’analisi e il monitoraggio delle attività del sistema. Ricorrendo a un comando come journalctl, gli amministratori possono filtrare e visualizzare i log in modo più efficace rispetto ai tradizionali file di testo, accedendo a una visione chiara e dettagliata degli eventi del sistema.

Ne abbiamo parlato in tanti nostri articoli: con il comando systemctl gli amministratori possono verificare facilmente lo stato dei servizi, avviarli e fermarli. Il tutto avvalendosi sempre di un’interfaccia centralizzata.

Cosa si intende per “Linux embedded”?

Alcune distro Linux hanno sempre preferito, per i motivi citati in precedenza e per altri che non abbiamo approfondito, evitare l’integrazione di systemd. Una delle alternative più “gettonate” è OpenRC, un sistema di init utilizzato in distribuzioni come Alpine Linux che nascono proprio per ridurre l’impatto sulle risorse di sistema e facilitare l’utilizzo della distro anche su configurazioni hardware modeste o mediocri.

Per Linux embedded si intende una versione del “pinguino” progettata per funzionare su dispositivi integrati, ossia su prodotti che non sono computer generici come PC o server, ma dispositivi specifici dedicati a una funzione particolare.

Alcuni esempi comuni di dispositivi embedded che utilizzano Linux includono router e modem, smart TV e set-top box, sistemi di infotainment per le autovetture, sistemi di automazione industriale, dispositivi IoT (Internet delle Cose) come termostati intelligenti e telecamere di sicurezza, smartphone (Android è un sistema basato su kernel Linux), console di gioco e lettori multimediali. I sistemi embedded spesso hanno risorse limitate in termini di memoria, potenza di calcolo e storage.

Perché systemd non è adatto ai sistemi Linux embedded

Come abbiamo visto in precedenza, l’adozione di systemd è motivata anche dai benefici che offre sui sistemi desktop moderni, soprattutto in termini di ottimizzazione del tempo di avvio e della gestione delle risorse tramite l’inizializzazione parallela dei processi. Vantaggi che, tuttavia, si rivelano poco significativi per i dispositivi embedded: qui il bilancio tra complessità del software e risorse disponibili è molto più critico.

Un sistema Linux embedded, come ad esempio un single-board computer Raspberry Pi 3B, ha risorse molto limitate che necessitano di una gestione ottimale. Anche nelle configurazioni più “parsimoniose”, systemd richiede più memoria rispetto alle alternative tradizionali (ad esempio lo storico init SystemV). Alcuni dati rilevati su una configurazione minimalista di DietPi (distribuzione Linux leggera e ottimizzata per dispositivi embedded e single-board computer, come Raspberry Pi e Odroid) su Raspberry Pi:

• Systemd init: impegna circa 170 MB di memoria virtuale e 8 MB in RAM.
• SystemV init: occupa meno di 3 MB di memoria virtuale e meno di 2 MB in RAM.

Se si estende la verifica ai daemon di logging la musica non cambia. Mentre systemd-journald utilizza circa 41 MB di memoria virtuale, una soluzione customizzata e ottimizzata per embedded, come syslogd-lite impegna solamente 1,9 MB. Il confronto è davvero impari.

L’aumento della complessità di systemd si riflette anche nei tempi di avvio: systemd introduce un ritardo aggiuntivo di circa mezzo secondo rispetto a SystemV. Un comportamento che è figlio delle dimensioni dei file binari che compongono systemd e delle tante librerie correlate.

Troppe funzionalità affossano le prestazioni di systemd

La già citata tendenza di systemd ad assorbire funzionalità originariamente indipendenti complica la situazione per chi desidera un sistema leggero. Un esempio è udev, il daemon di gestione dei dispositivi che originariamente era indipendente ma che ora è parte integrante di systemd. Sebbene siano stati sviluppati progetti alternativi come eudev, il loro sviluppo e supporto sono in calo, costringendo chi necessita di udev a fare affidamento sulla versione inclusa in systemd. Anche la compatibilità con daemon utili alla sincronizzazione dell’orologio di sistema, come Chrony e OpenNTPD, rischia di essere messa in discussione proprio dalla vorticosa evoluzione di systemd.

Quindi, se da un lato sempre più distribuzioni hanno abbracciato systemd perché fornisce un pacchetto completo e facilita la gestione, soprattutto per sistemi desktop o server, dall’altro le alternative per il mondo embedded cominciano a diventare più rare e più complesse da adottare. D’altra parte, systemd non è ottimizzato per dispositivi a bassa potenza.

Conclusioni

Per chi lavora nel mondo dell’embedded, la sfida è mantenere la flessibilità e l’efficienza necessarie, in un panorama in cui systemd è diventato quasi ineludibile. Per questo abbiamo citato con entusiasmo alternative come Alpine Linux che offrono una soluzione robusta, adatta anche ai dispositivi ultracompatti e a basso consumo energetico, che non integrano affatto systemd (così come altri componenti software più pesanti…).