Systemd: alla scoperta del nuovo demone di sistema

Quando accendiamo il PC e facciamo partire la nostra distribuzione Linux preferita, ci deve necessariamente essere un processo che si occupi dell’inizializzazione e dell’avvio di tutti i componenti necessari al funzionamento del sistema operativo. Questo processo, che fino a qualche anno fa si chiamava (quasi ovunque) init, è responsabile della corretta procedura di avvio di tutti gli altri processi principali. Da esso derivano molti effetti collaterali non irrilevanti, che incidono anche significativamente sulle performance del sistema (principalmente in fase di avvio, ma non solo).

Per molto tempo, le distribuzioni Linux si sono affidate a sistemi che non sfruttavano al meglio le caratteristiche di parallelizzazione che le moderne CPU offrono, impedendo (tra le altre cose) la riduzione dei tempi di avvio.  Nel 2010, però, Lennart Poettering, Kay Sievers “and many others”  hanno finalmente messo a punto un sistema di avvio molto più moderno, che si è fortemente diffuso nel giro di pochi anni, arrivando ad essere applicato su un grandissimo numero di distribuzioni Linux: si tratta di systemd (che si scrive così, senza la maiuscola iniziale). Introdotto, inizialmente, su Fedora 15 (la prima grande distribuzione che lo adottò ufficialmente) systemd oggi è divenuto stabilmente un componente fondamentale di moltissime distribuzioni Linux, rimpiazzando con merito i suoi predecessori.

In questo articolo vedremo brevemente cosa offre systemd, spiegandone per grandi linee il funzionamento. In seguito, vedremo alcuni utili comandi ad esso correlati, che ci consentiranno di operare ed ottenere informazioni sul sistema operativo e sui processi in esecuzione. Infine, mostreremo come sfruttare systemd per la gestione dell’esecuzione automatica di servizi all’avvio del sistema.

Systemd: cos’è e come funziona

In ogni sistema Unix-like, c’è sempre un processo identificato dal caratteristico PID pari ad 1. Questo processo è quindi il primo ad essere avviato dal kernel, ed è responsabile dell’inizializzazione dello user space durante la fase di avvio del sistema. Fino a qualche anno fa, tale processo era chiamato “init” (che era derivato dal processo di avvio di SysV) ed era utilizzato nella maggior parte dei sistemi operativi Linux. Esso aveva, però, il difetto principale di essere sostanzialmente lento, e l’unico tentativo di rimpiazzarlo che vale la pena citare fu Upstart, utilizzato su Ubuntu. Anche in questo caso, però, i miglioramenti non furono significativi, e solo systemd è riuscito a ridurre significativamente i tempi di avvio.

Per capire qual è il motivo per cui systemd ha migliorato la fase di inizializzazione dei sistemi operativi Linux, iniziamo col dire che un efficiente sistema di boot dovrebbe, al tempo stesso, eseguire il minor numeri di servizi (cioè soltanto quelli strettamente necessari all’avvio del sistema), e parallelizzare il più possibile la loro esecuzione. Di conseguenza, ci viene spontaneo supporre che un buon sistema di boot cercherà di rimandare l’avvio di un servizio come bluetoothd (il cui nome ne suggerisce le funzionalità principali), mentre darà priorità a servizi come syslog (responsabile della gestione dei log di sistema). Ed effettivamente, questo è proprio quello che systemd riesce ad implementare.

La figura precedente mostra in modo molto schematico il principio di funzionamento di systemd, messo a confronto con quello di SysV ed Upstart. L’idea che ha consentito a systemd di aumentare il livello di parallelizzazione è stata quella di modificare tutti i demoni dei servizi in modo che essi non richiedano l’inizializzazione dei socket principali, e demandando questa operazione ad una fase di inizializzazione precedente al lancio dei processi, gestita dallo stesso systemd. In tal modo, non solo i processi potranno essere eseguiti in parallelo (in quanto non ci sono problemi di dipendenze), ma se un processo dovesse essere arrestato in un qualsiasi momento, il suo riavvio sarà più rapido in quanto non sarà più necessario inizializzare le socket (operazione già effettuata in fase di avvio).

I comandi principali di systemd

Per tutte le distribuzioni che includono systemd, vi sono diverse utility che è possibile sfruttare per la gestione del sistema e dei servizi. Esse ci consentono di tenere traccia dei processi in esecuzione e dei servizi, di terminarli e di ottenere informazioni su di essi. Esistono molti tool che consentono di svolgere questo tipo di operazioni, alcuni anche grafici (come systemd-gtk di Fedora o systemd-gui su Debian), ma noi vedremo direttamente quali comandi possono esserci utili direttamente da riga di comando.

Il primo comando che ci interessa conoscere è systemctl. In accordo con la definizione tratta dalla pagina del relativo manuale, systemctl può essere utilizzato per analizzare lo stato dei servizi e del sistema quando essi sono gestiti tramite systemd. Tramite questo comando possiamo svolgere un grandissimo numero di attività, che elenchiamo di seguito:

visualizzare tutti i servizi in esecuzione:

systemctl

avviare, fermare o riavviare un servizio:

# Avvio
systemctl start nomeservizo
# Arresto
systemctl stop nomeservizio
# Riavvio
systemctl restart nomeservizio

In questo caso, gli stessi risultati si possono ottenere con i comandi seguenti:

# Avvio
service nomeservizo start
# Arresto
service nomeservizio stop
# Riavvio
service nomeservizio restart

visualizzare lo stato di un servizio, nonché se esso è in esecuzione o meno:

systemctl status nomeservizio

In alternativa, possiamo verificare se un servizio è attualmente in esecuzione utilizzando il comando seguente:

systemctl is-enabled foo.service; echo $?

abilitare o disabilitare l’avvio di un servizio in fase di boot del sistema operativo:

# Abilitare l’avvio del servizio in fase di boot
systemctl enable nomeservizio
# Disabilitare l’avvio del servizio in fase di boot
systemctl disable nomeservizio

attivare la funzionalità di Readahead:

sudo systemctl enable systemd-readahead-collect systemd-readahead-replay

Questa funzionalità è utilizzata per pre-caricare alcuni file in memoria cache, consentendo di velocizzare la fase di avvio del sistema.

I comandi visti rappresentano solo alcune delle funzionalità principali di gestione dei servizi che systemctl ci mette a disposizioni. Possiamo trovare maggiori dettagli facendo riferimento alla già citata pagina di manuale relativa a questo comando.

Un’altra interessante utility direttamente connessa con systemd è journalctl. Facendo ancora una volta riferimento alla definizione del manuale, questo comando può essere utilizzato per ottenere il contenuto del journal di systemd, contenente tutti i messaggi di log. Più precisamente, per mostrare il log di sistema, possiamo utilizzare il comando:

journalctl

Se invece vogliamo i messaggi di log di un solo programma eseguibile, la sintassi sarà la seguente:

journalctl /usr/bin/my_executable

oppure, conoscendo il PID del processo che vogliamo analizzare (e supponendo, per esempio, che sia 123):

journalctl _PID=123

Quelli visti sono solo due dei comandi che possono tornare utili nel caso in cui si utilizzi un sistema operativo Linux che adotti systemd come sistema di avvio. Ovviamente, esistono molti altri tool da potere adoperare per la gestione dei servizi e dei processi, e nulla ci vieta di utilizzarli.

I service file

Un’operazione molto utile e strettamente correlata con systemd è la possibilità di attivare un servizio all’avvio del sistema. Ancora più interessante, inoltre, è conoscere in che modo possiamo definire i servizi che vogliamo avviare; in altre parole, come scrivere un service file.

Un service file è un file con una struttura ben precisa (ampiamente documentata sul manuale di systemd), che systemd utilizza durante la fase di avvio per lanciare un servizio. Rispetto ai vecchi initscript (che venivano usati dai sistemi basati su init per il boot del sistema), i service file hanno la interessante peculiarità di essere molto più semplici e schematici, in quanto sono stati concepiti per specificare cosa essi debbano fare, e non come ciò debba essere fatto (a differenza degli initscript).

Per creare un service file, dobbiamo innanzitutto sapere che esso dovrà essere salvato in /usr/lib/systemd/system, con un nome del tipo nomeservizio.service. Creiamo, quindi, un file di testo vuoto nella posizione che abbiamo appena specificato, e chiamiamolo, per esempio, ilmioservizio.service. A questo punto, apriamo questo file con un editor di testo, e modifichiamone il contenuto in modo da definire un semplice service file:

[Unit]
Description=Descrizione del servizio
[Service]
ExecStart=/usr/bin/esempio
[Install]
WantedBy=graphical.target

In questo modo abbiamo specificato la descrizione del servizio che stiamo definendo, il comando che esso eseguirà, e ne abbiamo impostato il cosiddetto runlevel tramite l’opzione WantedBy che, in questo caso consentirà l’esecuzione in modalità grafica. Possiamo aggiungere altre opzioni, e rendere un file come questo molto più complicato di così; ma l’idea di base, come si capisce, è molto intuitiva.

A questo punto, se vogliamo far sì che al prossimo riavvio il servizio venga attivato da systemd, dobbiamo eseguire il comando (già visto):

systemctl enable ilmioservizio

Se vogliamo anche avviarlo subito dopo l’esecuzione, aggiungiamo anche:

systemctl start ilmioservizio

Per maggiori dettagli, rimandiamo al manuale di systemd, ma suggeriamo un interessante post di Alexander Patrakov.