Un servizio che passa in failed non ha bisogno di un riavvio immediato. Su un server, questa abitudine a volte cancella il messaggio che spiega il guasto, o rilancia un programma con una configurazione ancora non valida.
Iniziate individuando l’unità interessata, leggete il suo stato e il suo log, poi correggete la causa. La ripartenza verrà dopo.
Elencare le unità realmente in errore
Questo comando visualizza i servizi e le unità che systemd considera difettosi:
systemctl --failedAnnotate il nome completo, per esempio nginx.service o la-tua-applicazione.service. Un’unità exited non è necessariamente guasta: alcuni servizi eseguono un compito breve e poi si arrestano normalmente. Lo stato failed indica che un avvio, un comando di controllo o un processo monitorato è terminato con errore.
Per rivedere i servizi attivi, fermi e i loro stati, consultate anche l’elenco dei servizi con systemctl.
Leggere lo stato del servizio prima di qualsiasi riavvio
Sostituite nginx con la vostra unità. L’opzione --no-pager stampa il risultato direttamente nel terminale, evitando di rimanere in less durante una sessione SSH.
sudo systemctl status nginx --no-pagerPrestate particolare attenzione alla riga Active:, al codice di uscita e alle ultime righe visualizzate. Una porta già occupata, un percorso assente, un certificato illeggibile oppure una direttiva mal scritta compaiono spesso qui. Se il servizio avvia un binario che ha il proprio validatore, eseguite prima quel validatore. Per Nginx, ad esempio:
sudo nginx -tNon eseguite questo comando su una macchina che non utilizza Nginx. Ogni servizio ha la propria sintassi di verifica.
Salire al messaggio di errore con journalctl
systemctl status mostra solo un estratto. Il log dell’unità fornisce il contesto completo:
sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager-b limita la ricerca all’avvio corrente. -n 50 conserva le ultime 50 righe se il guasto è più antico. Per seguire un riavvio in diretta, utilizzate sudo journalctl -fu nginx in una seconda sessione SSH. La guida journalctl e i messaggi dell’ultimo avvio aiuta ad ampliare la diagnostica quando l’errore colpisce più servizi.
Correggere, riavviare e poi verificare
Dopo una modifica del file di un’unità o di un drop-in systemd, ricaricate la configurazione. Questo passaggio non riavvia il servizio.
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failedis-active deve rispondere active. Se il servizio ascolta su una porta, controllate anche la porta e fate un test dal client corretto. Una risposta active non garantisce che un’applicazione web, un proxy o un database accettino già le richieste.
Su un servizio critico, tenete aperta una seconda sessione SSH prima di un riavvio e copiate l’errore esatto nel vostro ticket o nelle vostre note. Eviterete di ripetere la stessa diagnosi al prossimo incidente.