systemd: servizi, unit e log

Partire dallo stato completo

systemctl status mostra stato, processo principale e righe recenti del journal. Il colore o la parola “failed” sono un riepilogo: la causa si trova spesso nelle righe immediatamente precedenti. Usare il nome completo della unit evita ambiguità tra servizio, socket, timer e mount.

systemctl status nome.service --no-pager
systemctl is-enabled nome.service
systemctl is-active nome.service

Un servizio può essere attivo ma non abilitato all’avvio, oppure abilitato ma fallire. Le tre domande sono distinte. La pagina Debian di systemd conferma il pacchetto, mentre le manpage Debian riflettono le opzioni disponibili.

Start, stop, reload e restart

start avvia, stop arresta e restart interrompe e riavvia. reload chiede al servizio di rileggere la configurazione senza un arresto completo, ma non tutte le unit lo supportano. Prima di un restart su un sistema remoto valutare se il servizio mantiene proprio la connessione usata per amministrarlo.

sudo systemctl reload nome.service
# se reload non è supportato e l’interruzione è accettabile:
sudo systemctl restart nome.service

Dopo l’azione, controllare stato e log invece di assumere il successo dall’assenza di output. Per un servizio esposto in rete, verificare anche che la porta prevista sia in ascolto e raggiungibile dal segmento corretto.

Abilitazione all’avvio

enable crea i collegamenti previsti dalla sezione Install della unit; non sempre avvia immediatamente il servizio. L’opzione --now combina le due azioni. Usarla soltanto quando la configurazione è pronta e l’avvio immediato è desiderato.

sudo systemctl enable --now nome.service
systemctl is-enabled nome.service

Alcune unit sono statiche e vengono attivate come dipendenza o tramite socket, timer o evento. Un messaggio che segnala una unit statica non è necessariamente un errore. Leggere systemctl cat e le dipendenze chiarisce il modello.

Filtrare il journal

Il journal può essere filtrato per unit, boot, priorità e intervallo temporale. Cominciare da una finestra stretta riduce il rumore. -b limita al boot corrente; -b -1 guarda il boot precedente quando il problema ha costretto a riavviare.

journalctl -u nome.service -b --no-pager
journalctl -u nome.service --since "today" --no-pager
journalctl -p warning -b --no-pager

La manpage di journalctl documenta filtri e campi. Non copiare log completi in spazi pubblici senza controllare nomi host, indirizzi, percorsi e altri dati locali.

Override locali, non copie complete

systemctl edit nome.service crea un drop-in locale. È preferibile a modificare il file fornito dal pacchetto, perché l’override rimane separato e visibile durante gli aggiornamenti. Scrivere soltanto le direttive necessarie e annotare la ragione.

sudo systemctl edit nome.service
sudo systemctl daemon-reload
systemctl cat nome.service

Dopo la modifica, il reload del manager aggiorna le definizioni; il servizio va poi ricaricato o riavviato secondo la sua semantica. Se l’override non serve più, rimuoverlo attraverso gli strumenti previsti e verificare il contenuto risultante.

Una sequenza per le unit fallite

systemctl --failed
systemctl status nome.service --no-pager
journalctl -u nome.service -b --no-pager

Leggere prima l’errore più specifico, poi controllare file, permessi, dipendenze e porte a cui fa riferimento. Azzerare lo stato failed non ripara la causa; serve soltanto a pulire l’indicatore dopo che il problema è stato corretto. Una diagnosi utile conserva l’ordine degli eventi.

Se il guasto appare soltanto al boot, confrontare il journal del boot interessato con un avvio riuscito e osservare le dipendenze ordinate. Un servizio può partire manualmente ma fallire durante l’avvio perché rete, mount o credenziali non sono ancora disponibili. Correggere l’ordinamento dichiarato o la dipendenza effettiva è più robusto di aggiungere una pausa arbitraria. Dopo la modifica, verificare sia l’avvio manuale sia un riavvio pianificato con accesso locale disponibile.