Systemd è il sistema di init e gestione dei servizi adottato dalla maggior parte delle distribuzioni Linux moderne.

Quando un demone non parte, quando un servizio si ferma subito dopo l’avvio o quando il boot sembra rallentare senza motivo, il punto di partenza giusto non è riavviare a caso: è raccogliere informazioni affidabili.

Il comando più utile è systemctl status, perché mostra subito stato, PID, ultimi
log e file unità coinvolto.

systemctl status nome-servizio.service
systemctl is-active nome-servizio.service
systemctl is-enabled nome-servizio.service

Se il servizio risulta failed, i log associati sono quasi sempre più importanti del messaggio di errore mostrato a schermo.

journalctl consente di filtrare per unità, per boot corrente e per livello di gravità.

In pratica, la combinazione tra systemctl status e journalctl -u permette di capire se il problema è un permesso errato, una porta già occupata, una configurazione mancante o un binario non trovato.

journalctl -u nome-servizio.service -b
journalctl -xeu nome-servizio.service
journalctl -p err..alert -b
journalctl -f -u nome-servizio.service

Quando l’errore sembra più generale e coinvolge l’avvio del sistema, systemd offre anche strumenti per l’analisi del boot.

systemd-analyze blame mostra quali unità hanno richiesto più tempo;
critical-chain evidenzia la catena di dipendenze che ha rallentato l’avvio;
list-units –failed aiuta a individuare subito i componenti bloccati.

Se il problema nasce da una dipendenza mal definita o da un target
sbagliato, questi comandi fanno risparmiare molto tempo.

systemd-analyze blame
systemd-analyze critical-chain
systemctl list-units –failed
systemctl get-default
systemctl list-dependencies multi-user.target

Dopo aver corretto il file unità o la configurazione dell’applicazione, conviene ricaricare systemd e ripetere il test in modo ordinato.

Se hai modificato un file .service, usa daemon-reload
prima di riavviare il servizio.

È anche utile leggere il contenuto effettivo dell’unità con systemctl cat, così da verificare eventuali
override in /etc/systemd/system/ e non solo il file originale.

Questo approccio rende il troubleshooting più prevedibile e riduce il rischio
di intervenire nel posto sbagliato.

systemctl cat nome-servizio.service
sudo systemctl daemon-reload
sudo systemctl restart nome-servizio.service
sudo systemctl status nome-servizio.service

Conclusione

In conclusione, quando parliamo di Troubleshooting su systemd significa seguire un percorso logico:
verificare lo stato, leggere i log, analizzare le dipendenze e solo alla fine applicare la correzione.

Con systemctl, journalctl e systemd-analyze puoi diagnosticare rapidamente la maggior parte dei problemi su Linux senza tentativi casuali.

Per gli amministratori e per chi sta imparando, questa è una delle competenze più utili per gestire un sistema in modo affidabile.

Fonti e riferimenti:
– man systemctl
– man journalctl
– man systemd-analyze
– systemd documentation ufficiale