Log di sistema su Linux: leggere journalctl e dmesg

Quando un computer Linux si comporta in modo strano, la risposta è quasi sempre scritta da qualche parte. Il problema è che i messaggi sono migliaia e, senza filtri, cercare quello giusto è come leggere un elenco telefonico. Su un sistema moderno gli strumenti principali sono due: journalctl, che interroga il registro di systemd, e dmesg, che mostra i messaggi del kernel. Conoscere una manciata di opzioni basta per arrivare al punto in pochi secondi.

Dove finiscono i messaggi

Sulle distribuzioni che usano systemd tutti i messaggi, dal kernel ai servizi, vengono raccolti da journald in un registro binario e indicizzato. Molte distribuzioni affiancano ancora rsyslog, che scrive file di testo in /var/log/, come syslog su Debian e Ubuntu o messages su Fedora e derivate. Alcuni programmi tengono inoltre registri propri: il server web in /var/log/nginx/, il gestore dei pacchetti in /var/log/apt/ o /var/log/dnf.log.

Il registro di journald può essere volatile, cioè tenuto solo in memoria e perso a ogni riavvio, oppure persistente su disco in /var/log/journal/. Se journalctl --list-boots mostra un solo avvio, il registro non viene conservato: basta creare la cartella /var/log/journal e riavviare il servizio systemd-journald, oppure impostare Storage=persistent in /etc/systemd/journald.conf.

journalctl: le opzioni che servono davvero

Lanciato da solo, journalctl mostra tutto dal più vecchio al più recente, aperto in un visualizzatore in cui si scorre con le frecce e si cerca con /. Le opzioni utili sono poche:

Le opzioni si combinano. Per esempio, gli errori del servizio SSH nell'ultima ora:

journalctl -u ssh -p err --since "1 hour ago"

Oppure tutto quello che è successo ieri pomeriggio tra le 15 e le 16:

journalctl --since "yesterday 15:00" --until "yesterday 16:00"

Le priorità

Ogni messaggio ha un livello di gravità, ereditato dalla tradizione di syslog. Dal più grave al meno grave: emerg, alert, crit, err, warning, notice, info, debug. Con -p warning vedi gli avvisi e tutto ciò che è più grave. Nel visualizzatore gli errori compaiono in rosso.

dmesg: i messaggi del kernel

dmesg legge il buffer circolare del kernel: riconoscimento dei dispositivi, driver che si caricano, errori di disco, memoria esaurita. Su molte distribuzioni richiede sudo. Le opzioni più comode:

• dmesg -T mostra orari leggibili invece dei secondi dall'avvio;
• dmesg -w segue i nuovi messaggi in diretta;
• dmesg --level=err,warn filtra per gravità.

Un uso tipico: colleghi una chiavetta USB che non compare. Con sudo dmesg -w aperto in un terminale, la colleghi e vedi subito se il kernel l'ha riconosciuta, con quale nome di dispositivo, ed eventualmente quale errore ha restituito.

Cosa cercare nei casi più comuni

• Disco che si guasta: righe con I/O error, blk_update_request o reset del collegamento SATA. Vanno prese sul serio e accompagnate da un controllo dei valori SMART.
• Memoria esaurita: le righe con Out of memory: Killed process indicano quale processo il kernel ha sacrificato. Si trovano con journalctl -k | grep -i "out of memory".
• Servizio che non parte: journalctl -u nome -b mostra quasi sempre il messaggio esatto, per esempio un errore di sintassi nel file di configurazione o una porta già occupata.
• Spegnimenti improvvisi: confrontare la fine dell'avvio precedente con journalctl -b -1 -e. Se il registro si interrompe di colpo senza le righe di arresto, il computer si è spento senza un comando ordinato, come avviene per un'interruzione di corrente o un problema di alimentazione.
• Tentativi di accesso: su un server esposto, journalctl -u ssh | grep "Failed password" mostra i tentativi falliti di accesso con password.

Quanto spazio occupano

Il registro persistente cresce ma ha dei limiti automatici, per impostazione predefinita una percentuale dello spazio del filesystem. Per vedere quanto occupa:

journalctl --disk-usage

Per ridurlo subito si può tenere solo un certo periodo o una certa dimensione:

sudo journalctl --vacuum-time=30d
sudo journalctl --vacuum-size=500M

Per un limite permanente si imposta SystemMaxUse= in journald.conf. I file di testo in /var/log sono invece gestiti da logrotate, che li ruota, comprime ed elimina secondo le regole in /etc/logrotate.d/. Cancellare i registri a mano con rm mentre il servizio li sta scrivendo è una cattiva idea: lo spazio può non liberarsi finché il processo non riapre il file.

Un metodo per non perdersi

Nel mio lavoro seguo sempre lo stesso ordine: prima delimito il periodo in cui è successo il problema, poi il servizio o il dispositivo coinvolto, infine la gravità. Tre filtri, combinati, trasformano decine di migliaia di righe in poche decine. Solo a quel punto leggo i messaggi uno per uno, partendo dal primo errore e non dall'ultimo: spesso gli errori successivi sono conseguenze del primo.

In sintesi

• journald raccoglie quasi tutto; rsyslog e i singoli programmi possono scrivere anche in /var/log.
• journalctl -b, -u, -p e --since permettono di restringere subito la ricerca.
• dmesg -T -w è lo strumento giusto per dispositivi, driver e problemi di hardware.
• Lo spazio dei registri si controlla con --disk-usage e si limita con --vacuum o SystemMaxUse.
• Si legge partendo dal primo errore del periodo interessato, non dall'ultimo.