dmesg: Lendo Mensagens do Ring Buffer do Kernel

dmesg: Lendo Mensagens do Ring Buffer do Kernel
Tempo de leitura: Cerca de 9 min Dificuldade: Intermediate

O Que Voce Vai Aprender

  • Como ler o ring buffer do kernel com dmesg para detectar problemas de boot e hardware
  • As opcoes que importam na pratica: timestamps, niveis de log e acompanhamento em tempo real
  • Como fazer triagem de falhas classicas: erros de I/O em disco, o OOM killer e dispositivos nao reconhecidos
  • Quando usar dmesg versus journalctl -k

Resumo Rapido

  • Comece com sudo dmesg -H (cores + paginador) para escanear todo o buffer
  • Use dmesg -T para timestamps reais, dmesg -w para acompanhar novos eventos
  • Filtre com dmesg -l err,warn, e grep -i para palavras-chave
  • Para logs que sobrevivam a um reboot, use journalctl -k (o ring buffer e volatil)

Premissas

  • SO: um Linux com systemd (familia Ubuntu / Debian / RHEL)
  • dmesg do util-linux (incluso em quase toda distribuicao)
  • Ler o buffer frequentemente requer sudo (explicado abaixo)

O Que e o dmesg?

Conclusao: dmesg imprime o ring buffer do kernel, uma area de memoria de tamanho fixo onde o kernel registra eventos de boot e hardware. E o seu ponto de entrada na camada mais baixa do SO.

dmesg (diagnostic message) mostra mensagens produzidas pelo kernel Linux. Elas se acumulam no ring buffer do kernel, uma regiao de tamanho fixo na memoria.

O kernel registra aqui deteccao de hardware, carregamento de drivers, hotplug de dispositivos, montagem de sistemas de arquivos e erros de I/O. Diferente dos logs de aplicacao, dmesg permite observar o que aconteceu nas camadas mais profundas do SO.

$ sudo dmesg
[    0.000000] Linux version 6.8.0-106-generic ...
[    0.004000] Memory: 16310632K/16777216K available ...
[    2.314551] usb 1-2: new high-speed USB device number 3 ...
[    2.461230] ata1.00: configured for UDMA/133

Como o buffer tem tamanho fixo, mensagens antigas sao sobrescritas por novas, e tudo e perdido ao reiniciar. Para logs que voce precisa manter, use journalctl -k (coberto abaixo).

Por Que Precisa de Root?

Conclusao: A maioria das distribuicoes define kernel.dmesg_restrict=1, bloqueando leituras sem privilegios. Execute sudo dmesg.

Ubuntu moderno e outros vem com a flag de hardening kernel.dmesg_restrict definida como 1, entao um usuario normal nao consegue ler o dmesg. Logs do kernel podem vazar enderecos e outros detalhes uteis para um atacante.

# Verificar a configuracao atual
$ sysctl kernel.dmesg_restrict
kernel.dmesg_restrict = 1

Se for 1, voce precisa de sudo. Se for 0, qualquer usuario pode ler o buffer.

$ sudo dmesg

Voce pode liberar o acesso para todos os usuarios permanentemente, mas ele e restrito por uma razao. Usar sudo por padrao e o habito mais seguro.

Como Interpretar a Saida?

Conclusao: O dmesg bruto e dificil de ler. Aprenda tres flags: -H (cores + paginador), -T (timestamps reais) e -x (mostrar nivel).

-H: escanear tudo com cores e paginador

$ sudo dmesg -H

-H (--human) ativa coloracao, tempo relativo formatado e um paginador (less) de uma so vez. E o comando ideal para uma primeira visao geral.

-T: quando aconteceu, em horario real

O padrao [ 2.314551] mostra segundos desde o boot. Para ver datas reais, use -T.

$ sudo dmesg -T
[Thu Jun  5 09:12:47 2026] usb 1-2: new high-speed USB device number 3 ...

O timestamp -T e reconstruido a partir do uptime e e aproximado. Pode haver desvio apos suspensao/retomada. Quando a precisao importa, confie em journalctl -k.

-x: mostrar nivel e facilidade

$ sudo dmesg -x
kern  :err   : [    3.821] EXT4-fs error (device sda1): ...
kern  :info  : [    2.314] usb 1-2: new high-speed USB device ...

Cada linha e prefixada com sua facilidade e nivel, tornando as linhas graves faceis de identificar.

Como Acompanhar em Tempo Real?

Conclusao: dmesg -w acompanha novas mensagens, permitindo correlacionar uma acao (conectar um drive USB) com a reacao do kernel.

$ sudo dmesg -w

-w (--follow) mantem o buffer aberto como tail -f e imprime cada nova mensagem do kernel conforme aparece. Conecte um pendrive USB e observe exatamente o que e detectado. Pressione Ctrl + C para parar.

Para pular as linhas existentes e ver apenas as novas, use dmesg -W (--follow-new). Util para testes de conectar/desconectar.

Como Filtrar por Nivel?

Conclusao: dmesg -l err,warn filtra por severidade. Os oito niveis sao emerg, alert, crit, err, warn, notice, info e debug.

Para encontrar uma falha enterrada sob uma enxurrada de linhas info, filtre por nivel.

# Mostrar apenas erros e avisos
$ sudo dmesg -l err,warn
[    3.821] EXT4-fs error (device sda1): ext4_find_entry: ...
[   12.044] ata1.00: failed command: READ FPDMA QUEUED

Limite a mensagens do kernel com -k (--kernel), ou filtre por facilidade com -f kern (--facility).

Para busca por palavra-chave, encaminhe para grep. Use -i para ignorar maiusculas/minusculas.

$ sudo dmesg | grep -i 'error\|fail\|warn'

Como Encontrar Problemas de Hardware e Boot?

Conclusao: Cada sintoma tem suas palavras-chave. Discos: ata / I/O error. Pressao de memoria: Out of memory. Dispositivos nao reconhecidos: usb / firmware.

Falhas de disco e armazenamento

$ sudo dmesg | grep -iE 'ata[0-9]|i/o error|ext4-fs|sd[a-z]'

I/O error, ata1.00: failed command ou EXT4-fs error indicam um disco ou conexao com falha. Verifique o layout dos dispositivos com lsblk / blkid.

Exaustao de memoria (o OOM killer)

Quando um processo morre sem razao aparente, o OOM killer e o principal suspeito.

$ sudo dmesg | grep -i 'out of memory\|oom-killer\|killed process'
[ 1843.221] Out of memory: Killed process 2217 (java) total-vm:4513980kB ...

Isso e o kernel matando um processo a forca sob pressao de memoria, e indica qual foi morto.

Dispositivos e drivers nao reconhecidos

$ sudo dmesg | grep -iE 'usb|firmware|failed to load|no such device'

firmware: failed to load ou failed to load geralmente significa um driver ou firmware ausente.

O ring buffer e volatil. Se ja passou algum tempo desde o incidente, as linhas relevantes podem ja ter sido sobrescritas. Nesse caso, verifique o boot anterior com journalctl -k --boot=-1.

dmesg vs journalctl: qual a diferenca?

Conclusao: dmesg e uma visualizacao instantanea de um buffer volatil; journalctl -k e o log persistente do kernel. Para voltar a boots anteriores, voce precisa do journalctl.

Aspecto dmesg journalctl -k
Fonte de dados ring buffer do kernel systemd-journald (pode persistir)
Sobrevive ao reboot nao (volatil) sim, se a persistencia estiver ativa
Ver boots anteriores nao sim, com --boot=-1
Precisao do timestamp aproximado com -T horario real preciso
Imediatismo / simplicidade alto mais funcionalidades 
# Log do kernel para o boot atual
$ journalctl -k

# Log do kernel para o boot anterior
$ journalctl -k --boot=-1

Use dmesg para ver o estado agora, e journalctl -k para rastrear e revisitar uma falha depois. Eles se complementam. Veja Como Usar o journalctl para detalhes.

Folha de Consulta de Comandos

Conclusao: Escaneie com sudo dmesg -H, filtre com -T / -w / -l, e persista com journalctl -k. Esse padrao cobre a maioria das investigacoes.

Modelo de triagem dmesg para copiar e colar

# Primeiro, escaneie com cores + paginador
sudo dmesg -H

# Verifique em tempo real
sudo dmesg -T

# Apenas erros e avisos
sudo dmesg -l err,warn

# Acompanhe novos eventos (testes de conectar/desconectar USB, etc.)
sudo dmesg -w

# Busca por palavra-chave baseada em sintoma
sudo dmesg | grep -iE 'i/o error|oom|firmware'

# Log persistente / boot anterior
journalctl -k --boot=-1

Proximas Leituras