Corso Linux / Indagare i guasti con i log e journalctl

Per indagare un guasto con i log, identifica prima il servizio coinvolto e l'ora del problema, raccogli i messaggi dello stesso avvio e fuso orario e confrontali con una riproduzione controllata. Una riga ERROR o l'ultimo messaggio non bastano a dimostrare la causa: servono contesto e riscontri sullo stato delle risorse.

Per il significato degli stati dei servizi consulta l'introduzione a systemd. Qui colleghi orari, stati e registrazioni per restringere le ipotesi; puoi applicare lo stesso metodo nella lezione sulla riproduzione dei guasti e il recupero (in inglese).

Gli ambienti di riferimento del corso sono macchine virtuali con installazioni convenzionali di Ubuntu 26.04 LTS o Rocky Linux 9. Container, WSL e altre versioni possono avere servizi e pacchetti diversi. Prepara la console di recupero e registra le versioni seguendo la lezione sull'ambiente di laboratorio in macchina virtuale (in inglese). Le prove del journal richiedono Linux con una raccolta funzionante: controllare la sintassi in Git Bash su Windows non verifica la raccolta o i filtri reali di journald.

Fissare sintomo, orario e modifiche recenti

Invece di «il server è guasto», annota un'osservazione precisa, per esempio «le richieste HTTPS dal client A restituiscono 502 dalle 14:03». Confronta orologi e fusi di client e server e registra l'ultimo funzionamento noto, le distribuzioni dell'applicazione, le modifiche di configurazione e i riavvii recenti. Il codice 502 descrive un sintomo, non dimostra da solo quale componente abbia causato il problema. Tieni separati fatti osservati e ipotesi da verificare.

date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-boots

date --iso-8601=seconds mostra anche lo scostamento del fuso; timedatectl aiuta a controllare l'orologio di sistema. systemctl --failed elenca unità fallite, mentre journalctl --list-boots mostra gli avvii per cui sono presenti registrazioni, con identificatori e intervalli temporali. Non dedurre la causa da un'unità fallita senza collegarla all'orario del sintomo.

Se manca un avvio precedente, il journal potrebbe non essere stato conservato o potrebbe essere già stato eliminato. Controlla memorizzazione volatile o persistente e limiti di conservazione di journald: lo spazio disponibile e le politiche possono limitare la storia consultabile. Anche i permessi possono nascondere parte dei dati. L'assenza di messaggi non dimostra l'assenza del guasto; non cambiare subito la politica di raccolta durante l'indagine senza considerare gli effetti sulle prove.

Filtrare il journal per unità, avvio e intervallo

Sostituisci NAME.service con il nome effettivo dell'unità coinvolta. Guarda prima lo stato e poi i messaggi dello stesso avvio, restringendo l'intervallo al momento del problema. Un intervallo mirato conservato per il confronto è più utile di un flusso illimitato di messaggi non correlati.

systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager

-u seleziona un'unità; -b senza un identificatore indica l'avvio corrente; -k seleziona i messaggi del kernel. Il terzo comando del blocco non è limitato a NAME.service: serve a cercare avvisi più generali nello stesso periodo. Il kernel può fornire riscontri su memoria, dispositivi e altri eventi, ma un messaggio vicino nel tempo non prova automaticamente un rapporto causale.

Secondo le regole dei filtri di journalctl, -p warning include warning e livelli più gravi, cioè i valori numerici da 0 a 4. Esclude notice, info e debug. Un'applicazione può assegnare priorità incoerenti o scrivere una spiegazione importante sul normale output: dopo il filtro confronta anche i messaggi senza filtro di priorità dello stesso intervallo.

Per un incidente storico scegli l'identificatore dell'avvio e un intervallo assoluto con --since e --until nel formato supportato dalla versione installata. La finestra relativa «30 minutes ago» cambia se ripeti la query più tardi. Registra quindi anche l'intervallo esatto e il fuso usati per il confronto. --no-pager disabilita il paginatore, non amplia i permessi di lettura.

Ritrovare un evento creato con logger

Il blocco registra due messaggi di prova senza modificare la configurazione di un servizio. Richiede logger e un percorso di raccolta che porti i suoi messaggi nel journal. Nei container limitati o nei sistemi senza un socket syslog funzionante il risultato può essere diverso. Esegui command -v logger journalctl e annota le versioni prima della prova; non installare o riavviare servizi di raccolta soltanto per forzare il risultato in produzione.

tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pager

Il tag usa l'identificatore numerico dell'utente, quindi distingue la prova per utente ma non è un identificatore nuovo a ogni esecuzione. Se ripeti il blocco entro cinque minuti potresti vedere messaggi precedenti con lo stesso tag: annota l'ora di ogni prova e riconosci i due testi esatti. journalctl -t filtra l'identificatore syslog, non l'unità del servizio.

Con util-linux logger, il primo messaggio usa per impostazione predefinita user.notice; il secondo specifica user.warning. Cerca entrambi con i rispettivi orari, poi ripeti la query finale aggiungendo -p warning: se priorità e raccolta sono preservate, il messaggio notice viene escluso e resta il warning. sample-warning è un evento creato apposta per l'esercizio, non un guasto reale. Il manuale logger del progetto util-linux descrive tag, priorità e socket.

Controlla lo stato di ogni comando subito dopo l'esecuzione. Il solo stato 0 di logger non prova che il journal abbia ricevuto il messaggio: in alcune configurazioni gli errori del socket possono non essere segnalati. Se non compare nulla, verifica raccolta, intervallo e permessi prima di trarre conclusioni. Usa soltanto privilegi autorizzati per leggere i log; non cancellare registrazioni né riavviare la raccolta per rendere visibile il campione. Lascia che i messaggi di prova seguano la normale politica di conservazione.

Confrontare i messaggi con prove indipendenti

Un errore di spazio può riguardare il percorso in cui l'applicazione tentava di scrivere, non il disco che contiene il log. df -h controlla lo spazio e df -i gli inode, le strutture che descrivono gli oggetti del file system: applicali alla risorsa corretta. Un diniego di accesso può dipendere dai permessi di attraversamento di una directory superiore o da una politica, non soltanto dal modo del file finale.

Verifica la risorsa nominata dal messaggio e ripeti il controllo nella stessa condizione del servizio. Non nascondere il sintomo eseguendo tutto come root o assegnando permessi 777. Un timeout non prova da solo che il firewall sia la causa; considera indirizzo, instradamento, servizio e dipendenze prima di modificare regole.

Controllare file di log e conservazione delle prove

Un'applicazione può scrivere in file sotto /var/log o in un collettore centrale anziché nel journal. Ricava il percorso dalla configurazione reale prima di usare tail -n 100 o grep sul file interessato. Considera anche file ruotati e archivi compressi, mantenendo coerenti formato degli orari e fuso. Per seguire una riproduzione, conserva un intervallo precedente e successivo al sintomo: le ultime cento righe da sole potrebbero non contenerlo.

journalctl --disk-usage mostra lo spazio dei file journal attivi e archiviati; non è lo spazio totale del file system. Cancellare o eseguire vacuum durante l'indagine può distruggere indizi. Conserva l'intervallo necessario in una directory con accesso limitato e separa una copia originale protetta da una copia per la condivisione, nella quale oscurare token, cookie, dati personali e indirizzi interni.

Quando applichi una correzione, registra la causa sostenuta dalle prove, la modifica mirata, il risultato della ripetizione nelle stesse condizioni e le incertezze residue. Se le prove non bastano, mantieni la spiegazione come ipotesi. Gestisci poi il materiale secondo la politica di conservazione, evitando che i file esportati diventino una copia incontrollata di informazioni sensibili.

Documentazione ufficiale

• journalctl: filtri, avvii e spazio occupato.
• journald: memorizzazione e conservazione.
• Distribuzioni ufficiali di util-linux, che comprende logger.