dmesg: Lendo Mensagens do Ring Buffer do Kernel

dmesg: Lendo Mensagens do Ring Buffer do Kernel
Tempo de leitura: Cerca de 9 min Dificuldade: Intermediário+

O Que Você Vai Aprender

  • Como ler o ring buffer do kernel com dmesg para detectar problemas de boot e hardware
  • As opções que importam na prática: timestamps, níveis de log e acompanhamento em tempo real
  • Como fazer triagem de falhas clássicas: erros de I/O em disco, o OOM killer e dispositivos não reconhecidos
  • Quando usar dmesg versus journalctl -k

Resumo Rápido

  • 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 é volatil)

Premissas

  • SO: um Linux com systemd (família Ubuntu / Debian / RHEL)
  • dmesg do util-linux (incluso em quase toda distribuição)
  • Ler o buffer frequentemente requer sudo (explicado abaixo)

O Que é o dmesg?

Conclusão: dmesg imprime o ring buffer do kernel, uma área de memória de tamanho fixo onde o kernel registra eventos de boot e hardware. É 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 região de tamanho fixo na memória.

O kernel registra aqui detecção de hardware, carregamento de drivers, hotplug de dispositivos, montagem de sistemas de arquivos e erros de I/O. Diferente dos logs de aplicação, 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 são sobrescritas por novas, e tudo é perdido ao reiniciar. Para logs que você precisa manter, use journalctl -k (coberto abaixo).

Por Que Precisa de Root?

Conclusão: A maioria das distribuições define kernel.dmesg_restrict=1, bloqueando leituras sem privilégios. Execute sudo dmesg.

Ubuntu moderno e outros vêm com a flag de hardening kernel.dmesg_restrict definida como 1, então um usuário normal não consegue ler o dmesg. Logs do kernel podem vazar endereços e outros detalhes úteis para um atacante.

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

Se for 1, você precisa de sudo. Se for 0, qualquer usuário pode ler o buffer.

$ sudo dmesg

Você pode liberar o acesso para todos os usuários permanentemente, mas ele é restrito por uma razão. Usar sudo por padrão é o hábito mais seguro.

Como Interpretar a Saída?

Conclusão: O dmesg bruto é difícil de ler. Aprenda três flags: -H (cores + paginador), -T (timestamps reais) e -x (mostrar nível).

-H: escanear tudo com cores e paginador

$ sudo dmesg -H

-H (--human) ativa coloração, tempo relativo formatado e um paginador (less) de uma só vez. É o comando ideal para uma primeira visão geral.

-T: quando aconteceu, em horário real

O padrão [ 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 é reconstruído a partir do uptime e é aproximado. Pode haver desvio após suspensão/retomada. Quando a precisão importa, confie em journalctl -k.

-x: mostrar nível 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 é prefixada com sua facilidade e nível, tornando as linhas graves fáceis de identificar.

Como Acompanhar em Tempo Real?

Conclusão: dmesg -w acompanha novas mensagens, permitindo correlacionar uma ação (conectar um drive USB) com a reação do kernel.

$ sudo dmesg -w

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

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

Como Filtrar por Nível?

Conclusão: dmesg -l err,warn filtra por severidade. Os oito níveis são emerg, alert, crit, err, warn, notice, info e debug.

Para encontrar uma falha enterrada sob uma enxurrada de linhas info, filtre por nível.

# 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 maiúsculas/minúsculas.

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

Como Encontrar Problemas de Hardware e Boot?

Conclusão: Cada sintoma tem suas palavras-chave. Discos: ata / I/O error. Pressão de memória: Out of memory. Dispositivos não 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 conexão com falha. Verifique o layout dos dispositivos com lsblk / blkid.

Exaustão de memória (o OOM killer)

Quando um processo morre sem razão aparente, o OOM killer é 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 é o kernel matando um processo à força sob pressão de memória, e indica qual foi morto.

Dispositivos e drivers não 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 é volatil. Se já passou algum tempo desde o incidente, as linhas relevantes podem já ter sido sobrescritas. Nesse caso, verifique o boot anterior com journalctl -k --boot=-1.

dmesg vs journalctl: qual a diferença?

Conclusão: dmesg é uma visualização instantânea de um buffer volatil; journalctl -k é o log persistente do kernel. Para voltar a boots anteriores, você precisa do journalctl.

Aspecto dmesg journalctl -k
Fonte de dados ring buffer do kernel systemd-journald (pode persistir)
Sobrevive ao reboot não (volatil) sim, se a persistência estiver ativa
Ver boots anteriores não sim, com --boot=-1
Precisão do timestamp aproximado com -T horário 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

Conclusão: Escaneie com sudo dmesg -H, filtre com -T / -w / -l, e persista com journalctl -k. Esse padrão cobre a maioria das investigações.

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

Próximas Leituras