debugbashMajor
dmesg: Reading Kernel Ring Buffer for Hardware and Boot Diagnostics
Viewed 0 times
dmesgkernelOOM killerhardware errorring bufferboot messagesata error
linux
Error Messages
Problem
Hardware errors, driver failures, and OOM kill events are not visible in application logs — they appear only in the kernel ring buffer.
Solution
Use dmesg with filters and human-readable timestamps to diagnose kernel-level events.
# Basic dmesg with human timestamps
dmesg -T
# Follow kernel messages in real time
dmesg -Tw
# Filter by log level (err, warn, crit, etc.)
dmesg -l err,crit
# Filter since last boot
dmesg -T | head -50
# Search for specific hardware errors
dmesg | grep -i 'error\|fail\|oom\|killed'
# OOM killer events (process killed for out of memory)
dmesg | grep -i 'Out of memory\|oom_kill'
# USB device events
dmesg | grep -i usb
# Disk errors (SCSI/ATA)
dmesg | grep -i 'ata\|scsi\|error\|reset'
# Check if kernel messages are also in journal
journalctl -k -p errWhy
dmesg reads the kernel ring buffer — a circular in-memory log. It contains events that happen before syslog starts (boot) and kernel-level events that bypass userspace logging entirely.
Gotchas
- The ring buffer has finite size — old messages are overwritten on busy systems; capture early with
dmesg > /tmp/dmesg.txt. - On older kernels, dmesg -T may show inaccurate timestamps if the system clock was adjusted.
- On RHEL/CentOS,
dmesgmay require sudo since kernel 3.4 (kernel.dmesg_restrict=1). - OOM kills are critical events — a process being killed by the OOM killer does NOT produce an application error log.
Revisions (0)
No revisions yet.