dmesg: Reading Kernel Ring Buffer Messages

dmesg: Reading Kernel Ring Buffer Messages
Reading time: About 9 min Difficulty: Intermediate

What You'll Learn

  • How to read the kernel ring buffer with dmesg to spot boot and hardware problems
  • The options that matter in practice: timestamps, log levels, and live follow
  • How to triage classic faults: disk I/O errors, the OOM killer, and unrecognized devices
  • When to reach for dmesg versus journalctl -k

Quick Summary

  • Start with sudo dmesg -H (colors + pager) to scan the whole buffer
  • Use dmesg -T for real timestamps, dmesg -w to follow new events
  • Narrow down with dmesg -l err,warn, and grep -i for keywords
  • For logs that survive a reboot, use journalctl -k (the ring buffer is volatile)

Assumptions

  • OS: a systemd Linux (Ubuntu / Debian / RHEL family)
  • dmesg from util-linux (shipped by almost every distro)
  • Reading the buffer often requires sudo (explained below)

What is dmesg?

Conclusion: dmesg prints the kernel ring buffer, a fixed-size memory area where the kernel records boot and hardware events. It is your entry point into the lowest layer of the OS.

dmesg (diagnostic message) shows messages produced by the Linux kernel. They accumulate in the kernel ring buffer, a fixed-size region in memory.

The kernel writes hardware detection, driver loading, device hotplug, filesystem mounts, and I/O errors here. Unlike application logs, dmesg lets you observe what happened deep inside the OS.

$ 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

Because the buffer has a fixed size, old messages are overwritten by new ones, and everything is lost on reboot. For logs you need to keep, use journalctl -k (covered below).

Why does it need root?

Conclusion: Most distros set kernel.dmesg_restrict=1, blocking unprivileged reads. Run sudo dmesg.

Modern Ubuntu and others ship with the kernel.dmesg_restrict hardening flag set to 1, so a normal user cannot read dmesg. Kernel logs can leak addresses and other details useful to an attacker.

# Check the current setting
$ sysctl kernel.dmesg_restrict
kernel.dmesg_restrict = 1

If it is 1, you need sudo. If it is 0, any user can read the buffer.

$ sudo dmesg

You can open it up to all users permanently, but it is restricted for a reason. Defaulting to sudo is the safer habit.

How do you read the output?

Conclusion: Raw dmesg is hard to read. Learn three flags: -H (colors + pager), -T (real timestamps), and -x (show level).

-H: scan everything with colors and a pager

$ sudo dmesg -H

-H (--human) turns on coloring, formatted relative time, and a pager (less) in one shot. It is the go-to for a first overview.

-T: when did it happen, in wall-clock time

The default [ 2.314551] is seconds since boot. To see actual dates, use -T.

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

The -T timestamp is reconstructed from uptime and is approximate. It can drift across suspend/resume. When exact times matter, trust journalctl -k instead.

-x: show the level and facility

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

Each line is prefixed with its facility and level, making serious lines easy to spot.

How do you watch it live?

Conclusion: dmesg -w follows new messages, letting you correlate an action (plugging in a USB drive) with the kernel's reaction.

$ sudo dmesg -w

-w (--follow) keeps the buffer open like tail -f and prints each new kernel message as it appears. Plug in a USB stick and watch exactly what gets detected. Press Ctrl + C to stop.

To skip existing lines and only see new ones, use dmesg -W (--follow-new). Handy for plug/unplug testing.

How do you filter by level?

Conclusion: dmesg -l err,warn narrows by severity. The eight levels are emerg, alert, crit, err, warn, notice, info, and debug.

To find a fault buried under a flood of info lines, filter by level.

# Show only errors and warnings
$ sudo dmesg -l err,warn
[    3.821] EXT4-fs error (device sda1): ext4_find_entry: ...
[   12.044] ata1.00: failed command: READ FPDMA QUEUED

Limit to kernel messages with -k (--kernel), or filter by facility with -f kern (--facility).

For keyword search, pipe into grep. Use -i to ignore case.

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

How do you find hardware and boot problems?

Conclusion: Each symptom has its keywords. Disks: ata / I/O error. Memory pressure: Out of memory. Unrecognized devices: usb / firmware.

Disk and storage faults

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

I/O error, ata1.00: failed command, or EXT4-fs error point to a failing disk or connection. Cross-check the device layout with lsblk / blkid.

Memory exhaustion (the OOM killer)

When a process dies for no obvious reason, the OOM killer is a prime suspect.

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

This is the kernel force-killing a process under memory pressure, and it tells you which one was killed.

Unrecognized devices and drivers

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

firmware: failed to load or failed to load usually means a missing driver or firmware.

The ring buffer is volatile. If a while has passed since the incident, the relevant lines may already be overwritten. In that case, check the previous boot with journalctl -k --boot=-1.

dmesg vs journalctl: what's the difference?

Conclusion: dmesg is an instant view of a volatile buffer; journalctl -k is the persisted kernel log. To go back to earlier boots, you need journalctl.

Aspect dmesg journalctl -k
Data source kernel ring buffer systemd-journald (can persist)
Survives a reboot no (volatile) yes, if persistence is on
View previous boots no yes, with --boot=-1
Timestamp accuracy approximate with -T accurate wall-clock time
Immediacy / simplicity high more featureful 
# Kernel log for the current boot
$ journalctl -k

# Kernel log for the previous boot
$ journalctl -k --boot=-1

Use dmesg to see the state right now, and journalctl -k to trace and revisit a fault later. They complement each other. See How to Use journalctl for details.

Command cheat sheet

Conclusion: Scan with sudo dmesg -H, narrow with -T / -w / -l, and persist with journalctl -k. This pattern covers most investigations.

Copy-paste dmesg triage template

# First, scan with colors + pager
sudo dmesg -H

# Check in real time
sudo dmesg -T

# Errors and warnings only
sudo dmesg -l err,warn

# Follow new events (USB plug/unplug tests, etc.)
sudo dmesg -w

# Symptom-based keyword search
sudo dmesg | grep -iE 'i/o error|oom|firmware'

# Persistent log / previous boot
journalctl -k --boot=-1

Next Reading