Comando dmesg in Linux: leggere e filtrare i messaggi del kernel

dmesg legge i messaggi conservati nel buffer circolare del kernel Linux. È utile per indagare sul riconoscimento dell'hardware, sui driver, sui filesystem e sugli avvisi emessi durante l'avvio o il funzionamento del sistema.

Il buffer ha capacità limitata: quando arrivano nuovi messaggi, quelli più vecchi possono essere sovrascritti. La consultazione ordinaria non modifica il buffer, ma alcune opzioni di dmesg lo svuotano: per leggere i log usa gli esempi seguenti, evitando le opzioni di cancellazione.

Sintassi di base

dmesg [opzioni]

Le parentesi indicano opzioni facoltative e non vanno digitate. Senza opzioni, il comando mostra i messaggi ancora disponibili nel buffer, con livelli di priorità diversi. La guida si riferisce a dmesg di util-linux: altre implementazioni possono avere opzioni differenti. Verifica man dmesg e dmesg --help sul sistema interessato.

Esempi di utilizzo

Scorrere i messaggi del kernel

dmesg | less

La pipeline passa l'output a less, un visualizzatore che deve essere installato. Usa le frecce o Pagina su/Pagina giù per scorrere, /testo per cercare e q per uscire. Vedrai anche i messaggi di avvio ancora conservati, ma il buffer non è un archivio completo di tutti gli avvii.

Selezionare errori e avvisi

dmesg --level=err,warn

Questo filtro include esattamente i livelli err e warn. Non include automaticamente crit, alert ed emerg, che sono più gravi. Per un'indagine più ampia considera l'elenco esplicito --level=emerg,alert,crit,err,warn; il filtro riguarda la priorità registrata, non la presenza delle parole «error» o «warning» nel testo.

Seguire l'arrivo di nuovi messaggi

dmesg --follow

Mostra i messaggi disponibili e rimane in attesa dei successivi; interrompi con Ctrl+C. Non modifica la configurazione del kernel. Il supporto richiede un dispositivo /dev/kmsg leggibile, disponibile nei kernel Linux dalla versione 3.5. Per iniziare soltanto dai nuovi messaggi, util-linux offre anche --follow-new, se presente nella versione installata.

Leggere messaggi e tempi relativi

Il formato temporale predefinito indica normalmente secondi dall'avvio, seguiti dal testo del messaggio. Il comando seguente filtra prima gli errori e gli avvisi, poi conserva fino alle ultime tre righe dell'output filtrato:

dmesg --level=err,warn | tail -n 3

Questa singola riga illustra soltanto il formato: non è un risultato misurato né implica che il comando produca sempre tre righe. Un messaggio può occupare più righe.

[   12.345678] device: warning message

Il numero tra parentesi quadre è un riferimento temporale relativo, non un'ora del calendario. Con -T puoi ottenere date e orari leggibili, ma la conversione può essere inesatta: il manuale segnala in particolare i cicli di sospensione e ripresa. Anche una correzione dell'orologio può complicare il confronto tra orari. Quando la sequenza temporale conta, confronta i messaggi con il journal dello stesso avvio e considera eventuali correzioni dell'ora; nessuna conversione ricostruisce da sola un timestamp mancante.

Un output vuoto può significare che nel buffer attuale non ci sono righe dei livelli scelti. Un errore di lettura o di autorizzazione è invece un problema distinto e normalmente compare sullo standard error. Nelle pipeline, lo stato finale può essere quello di tail o less: per diagnosticare un errore, esegui prima dmesg --level=err,warn senza pipeline e controlla subito echo $?.

Su un sistema con systemd, journalctl -k -b -1 interroga i messaggi del kernel dell'avvio precedente disponibile nel journal. Può funzionare solo se quei dati sono stati raccolti, conservati e sono accessibili all'utente. Usa journalctl --list-boots per vedere gli avvii disponibili; dmesg non recupera dal buffer corrente i messaggi già sovrascritti o persi con un riavvio. Le opzioni sono descritte nel manuale sorgente ufficiale di journalctl.

Opzioni principali

Precauzioni durante la consultazione

Se compare «Permission denied», verifica la politica del sistema. Il parametro dmesg_restrict può richiedere la capacità CAP_SYSLOG per la lettura; non disattivare le protezioni per aggirare il problema. Se sei autorizzato ad amministrare quella macchina, puoi usare sudo dmesg secondo la politica locale; nei container anche un utente root può non avere le capacità necessarie. La documentazione del kernel su dmesg_restrict descrive questa restrizione.

-c o --read-clear stampa e poi svuota il buffer; -C o --clear lo svuota senza la normale stampa. Non usarli per una semplice verifica. Un filtro senza risultati non dimostra che il sistema sia privo di problemi: il messaggio può avere un'altra priorità, essere stato sovrascritto o non essere mai stato registrato.

Domande frequenti

dmesg e journalctl -k mostrano gli stessi dati?

Entrambi consentono di leggere messaggi del kernel, ma usano fonti diverse. dmesg consulta il buffer circolare corrente; journalctl -k cerca le voci del kernel raccolte nel journal e, senza una diversa selezione con -b, si limita all'avvio corrente. La conservazione, i permessi e il formato temporale possono produrre risultati differenti; per un avvio precedente serve una selezione esplicita e un journal che ne conservi i dati.

Documentazione di riferimento

Il manuale dmesg di util-linux descrive filtri, formati temporali, modalità di attesa e opzioni che modificano il buffer. Confrontalo con il manuale locale prima di usare opzioni non presenti negli esempi.