Systemd: cosa è successo durante il mio boot?

Non ti piace Systemd perché pensi che sia il male? Leggi questo disclaimer prima di commentare.

Introduzione

Vi sarà sicuramente capitato di avviare il vostro sistema e scoprire solo in seguito che uno dei servizi non si è avviato correttamente. Purtroppo a volte gli script di init mentono (colpa dei servizi ovviamente, non di init): possiamo trovare nella lista dell’attivazione durante il boot il classico [OK], ma in realtà il servizio ha patito una la brutta morte anche solo un secondo dopo quella scritta. Allo stesso modo, la velocità di boot con l’aggiunta di maschere grafiche come plymouth possono nascondere un eventuale [FAIL]. In entrambi i casi, l’unico modo per sapere se tutti i servizi sono attivi tramite init è eseguire la chiamata “status” su ognuno di essi o cercarli in un “ps aux”.

Systemd

Per risolvere questo problema esistono diverse soluzioni, alcune delle quali comportano il cambiamento dell’intero init, altre utilizzando strumenti esterni. In questa sezione però si vuole mostrare come systemd reagisce a queste problematiche. Superata la fase di boot, possiamo invocare il comando:

systemctl status

in caso di problema rilevato, otterremo un output simile a quello in figura:

systemd-boot-fail-1

Lo stato “degraded” può essere avvenuto in fase di boot o successivamente in qualsiasi momento, vuoi per la morte di un servizio per un segmentation fault, vuoi per altra causa.

Per capire quale unità (nel nostro caso è un servizio) è andato in fallimento, basterà eseguire il comando:

systemctl

Scorrendo i risultati otteniamo:

systemd-boot-fail-2
Ovviamente possiamo indicare al comando di mostrare solo i servizi su cui sono stati rilevati problemi utilizzando il parametro “failed”:

systemctl --failed

Arrivati a questo punto non ci resta che cercare di scoprire il perché del fallimento in modo da assicurarci che non capiti nuovamente. Solitamente si prega che in qualche file di log sia presente qualche informazione utile. Il più delle volte sono i servizi stessi che prima di suicidarsi scrivono le loro ultime note, in altri casi è un agente “esterno” (esempio il kernel che nel syslog registra un processo ucciso per out of memory), in altri casi abbiamo il nulla cosmico (esempio servizio con esce con codice diverso da zero, senza però dare spiegazioni nei log).

In systemd possiamo interrogare lo stato del servizio la cui esecuzione è passata a miglior vita con il seguente comando:

systemctl status nomeservizio.service

Nel nostro esempio abbiamo:

systemd-boot-fail-3

Possiamo notare che systemd ha registrato esattamente quando il servizio ha smesso di funzionare (utile per cercare altre possibili anomalie nei log della macchina), il codice di errore del programma o il signal che ha portato alla sua morte e le ultime righe di log relative al servizio. In questo esempio l’errore era causato dai privilegi errati in una delle cartelle del servizio.

Conclusioni

Rispetto all’usuale init, systemd permette di tracciare vita e morte dei servizi e delle “unità” (concetto che probabilmente verrà spiegato nel futuro) semplificando la vita del sistemista durante le operazioni di monitoraggio dello stato di salute della macchina e di reazione in caso di anomalia. Nel prossimo articolo cercherò di mostrare alcune alternative (runit e supervisord).

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.