dmesg Command: Tutorial & Examples

The kernel talking directly to you — every disk error, every USB plug, every OOM kill.

What It Is

dmesg prints the kernel ring buffer — the running diary the Linux kernel keeps of everything it notices about your machine. Every device plugged in or pulled out, every disk that returned a read error, every network interface that lost link, every time the out-of-memory killer reached out and ended a process to keep the box alive — the kernel writes a line about it, and dmesg is how you read those lines.

That makes dmesg the single best place to look the moment you suspect a physical problem. journalctl owns the userspace story (every systemd unit, every login, every cron run); dmesg owns the kernel story (every driver, every piece of hardware, every event below userspace). They're siblings. When a USB stick won't mount, when a disk starts throwing I/O errors, when your MySQL "randomly disappeared at 3am" — dmesg is where the truth was recorded first.

It's installed on every Linux system, needs no setup, and like top, ps, and free, it's not doing anything mysterious — it just reads a buffer the kernel writes to and prints it. The buffer itself is the interesting part, and the next section is about that.

Your First Look

The single most useful invocation, and the one nine veterans out of ten reach for first:

dmesg -T | tail -20

[Wed May 27 20:36:02 2026] input: Surface Keyboard as /devices/virtual/misc/uhid/0005:045E:0917.0096/input/input548
[Wed May 27 20:36:02 2026] hid-generic 0005:045E:0917.0096: input,hidraw5: BLUETOOTH HID v1.30 Keyboard [Surface Keyboard] on 04:6c:59:0f:67:f1
[Wed May 27 22:27:51 2026] i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe B (start=893836 end=893837) time 2387 us
[Thu May 28 00:04:08 2026] audit: type=1400 audit(1779919455.451:191): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/paperspecs"

The -T is for human-readable timestamps (without it you get [1234567.890123] — seconds since boot, useless when you want to correlate with a real-world event). The shape of each line is the same: [timestamp] subsystem-or-driver: message. The subsystem might be a driver name (i915, nvme0n1, usb, ath11k), a kernel facility (audit, Memory, tcp), or the bare word kernel. The message is the actual event.

Nobody reads the whole buffer top-to-bottom — it can be thousands of lines, going all the way back to boot. The real session always starts with a filter: tail, grep, -l err, or the follow mode in the Pro Tip below.

How I Read It

When something feels wrong on a server and I'm not sure what kind of wrong, here's the order of moves, in maybe ten seconds total.

First: dmesg -T | tail -50. Just the last fifty lines, with real timestamps. Nine times out of ten the smoking gun is right there — a USB device that just dropped, a disk I/O error from twenty seconds ago, an OOM kill from last night. The kernel writes the diagnosis in plain English; you just have to look.

Second: filter to errors and warnings only. Most of the buffer is friendly boot chatter — drivers saying hello, firmware versions, ACPI tables. The interesting lines are the loud ones:

dmesg -T -l err,warn

-l takes a comma-separated list of severity levels (the syslog priorities — same eight buckets journalctl -p uses: emerg, alert, crit, err, warn, notice, info, debug). Keeping only err and warn collapses thousands of lines to the handful that actually want your attention.

Third: the OOM check. Any time a database or worker "just vanished," before anything else:

dmesg -T | grep -i -E 'oom|killed process'

If the OOM killer fired, you'll see the whole forensic report — which process it killed, its PID, how much RAM it was using, and the score table of every other process it considered. This is the only place that record exists with full context; journalctl sometimes mirrors the message via the kernel feed, but dmesg is the source.

Pro Tip

dmesg -T -w is follow mode — like tail -f for the kernel. Run it in a tmux pane while you plug in a USB stick, swap an SSD, bring a network cable up and down, or load a kernel module with modprobe, and watch the events appear in real time with human timestamps. It's the closest thing Linux has to seeing the machine think, and the first time you use it on hardware that's misbehaving, the problem usually identifies itself in seconds.

The Buffer, Explained

Here's the genuinely surprising thing about dmesg, and it's the part that makes the whole tool make sense: the kernel has its own log, in its own RAM, completely independent of syslog, rsyslog, or journald. Every time a driver or a kernel subsystem calls printk() — the in-kernel printf — that line is written to a small, fixed-size circular buffer that lives in kernel memory. Old messages get overwritten by new ones once it's full. This buffer existed before syslog, it predates systemd by decades, and it would still work on a Linux box where you'd uninstalled every userspace logger on earth — because the kernel is the thing writing it, and the kernel is always running.

The modern interface to this buffer is the special file /proc/kmsg (read by the syslog daemon) and /dev/kmsg (the read/write character device most userspace tools, including dmesg itself on modern Linux, now use). The buffer's size is set at kernel build/boot time — typically 128 KiB to 1 MiB on a desktop, sometimes larger on servers (sysctl kernel.printk and friends; the boot parameter is log_buf_len=). Check yours by running dmesg right after boot and counting the bytes, or check dmesg --buffer-size.

Warning

the kernel ring buffer is fixed-size and lives in RAM — when it fills up, the oldest messages are silently overwritten, and they're gone forever on the next reboot. If your box ran out of memory last Tuesday and the OOM killer ate your database, the dmesg evidence may have already scrolled off by the time you SSH in to investigate. The fix: rely on journalctl -k (which persists across boots if /var/log/journal/ exists) and on rsyslog shipping kernel facility messages to /var/log/kern.log and /var/log/syslog — those are durable; the live dmesg buffer is not.

Every line in the buffer carries a facility (almost always kern, but see --facility) and a level — eight syslog severities, 0 emerg through 7 debug. That's where dmesg -l err,warn gets its vocabulary, and it's the same priority table syslog and journalctl use.

The Flags, Explained

Every flag worth knowing, in rough order of usefulness:

-T, --ctime — human-readable timestamps. Always use this. Without it you get seconds-since-boot, which requires mental math against uptime. (Caveat in the man page: -T may drift across suspend/resume — the kernel timestamps in monotonic seconds and dmesg converts; if the box slept, the wall clock and monotonic clock disagree.)
-w, --follow — wait for new messages and print them as they arrive. The Pro Tip above. -W is "follow new only" (skip the existing buffer).
-l <list>, --level — restrict to severity levels: emerg,alert,crit,err,warn,notice,info,debug. Comma-separated. -l err,warn is the classic triage.
-f <list>, --facility — restrict to facilities (kern, user, daemon, auth, …). Almost everything in the kernel buffer is kern; the others come from --userspace writes via logger.
-k, --kernel — kernel messages only. -u, --userspace — userspace messages only (lines written into /dev/kmsg from outside the kernel).
-H, --human — pretty pager output with colors, relative times, and section dividers. Nice for interactive reading.
-x, --decode — prepend facility.level : to each line (e.g. kern :err :) so you can see the severity at a glance.
-e, --reltime — human time plus delta from the previous line; great for spotting bursts.
-d, --show-delta — just the delta between consecutive lines.
-t, --notime — strip timestamps entirely; useful when piping into diff to compare two boots.
-J, --json — JSON output, one record per line; pipe into jq for structured filtering.
-c, --read-clear and -C, --clear — read-then-empty, or just empty. Needs root. Almost never the right move on a running server (you destroy evidence) — the legitimate use is "I just fixed the hardware, give me a clean slate to watch what happens next."
-P, --nopager — don't pipe into a pager. Default is to pager when stdout is a terminal.
--since <time> / --until <time> — restrict to a time window (modern util-linux). Accepts the same human phrases as journalctl ('1 hour ago', 'yesterday', ISO timestamps).
-F <file> / -K <file> — read from a saved file instead of the live buffer. Useful for forensics: cp /var/log/dmesg /tmp/ and analyze later.

Reading It by Example

The handful of dmesg lines you'll see again and again, and what each one means.

A disk going bad:

[Wed May 27 14:21:07 2026] sd 2:0:0:0: [sda] tag#42 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed May 27 14:21:07 2026] blk_update_request: I/O error, dev sda, sector 1924312

I/O error, dev sda is the kernel telling you a read or write to the disk failed at the hardware level. One stray line might be a cosmic ray; a pattern of them is a dying disk. Cross-check with smartctl -a /dev/sda for the SMART data and watch iostat -x 1 for the latency spike that usually accompanies it. See disk failing.

The OOM killer firing — the big one:

[Wed May 27 03:12:44 2026] mysqld invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[Wed May 27 03:12:44 2026] Out of memory: Killed process 1872 (mysqld) total-vm:8421532kB, anon-rss:7102348kB, file-rss:0kB

The line Out of memory: Killed process 1872 (mysqld) is the moment your "database mysteriously died at 3am" mystery is solved. Scrolling up gives you the score table — every process the kernel weighed before picking the victim — which often reveals the real culprit (a leaky web worker that pushed the box over). Cross-check RAM trends with free -h.

A USB device attaching:

[Wed May 27 09:14:18 2026] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[Wed May 27 09:14:18 2026] usb 1-2: New USB device found, idVendor=0781, idProduct=5567
[Wed May 27 09:14:18 2026] sd 6:0:0:0: [sdb] Attached SCSI removable disk

This is the kernel narrating "a USB stick just got plugged in, it became /dev/sdb." If the stick didn't mount, the missing third line tells you the kernel didn't get far enough — likely a permissions or udev issue, not the hardware.

A network link bouncing:

[Wed May 27 11:02:51 2026] e1000e: enp3s0 NIC Link is Down
[Wed May 27 11:02:53 2026] e1000e: enp3s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Two seconds of disconnect. One bounce is a cable nudge; a pattern points to a flaky switch port, a bad cable, or a failing NIC. See network failure.

A kernel oops or panic — a multi-line stack trace starting with BUG:, Oops:, or Kernel panic - not syncing:. The full register dump and backtrace is what kernel developers want to see; for you, the first line names the subsystem (kernel panic).

Cheat Sheet

The invocations worth memorizing:

dmesg -T | tail -50 — last 50 lines, human timestamps. The default move.
dmesg -T -w — follow live. The Pro Tip.
dmesg -T -l err,warn — only the lines that matter.
dmesg -T | grep -i oom — did the OOM killer fire?
dmesg -T | grep -i -E 'sda|nvme|i/o error' — disk trouble.
dmesg -T | grep -i usb — USB attach/detach history.
dmesg -H — pretty paged output with colors and relative time.
dmesg -x — show facility and level on each line.
dmesg --since '10 min ago' — only the recent buffer.
dmesg -J | jq '...' — JSON for structured filtering.
dmesg --buffer-size — how big is the ring buffer on this kernel?
sudo dmesg -C — clear the buffer (rarely the right answer).

How You'll Actually Use It

In real life dmesg lives in three moments. One: something physical misbehaves — a USB device won't mount, a disk is slow, a network port keeps flapping — you run dmesg -T | tail -50 and the kernel hands you the diagnosis. Two: a process disappeared and you don't know why — dmesg -T | grep -i -E 'oom|killed' answers it in one line. Three: you're installing new hardware or a kernel module and you want to watch the kernel react in real time — dmesg -T -w in one pane while you work in another.

For the "why did the box reboot" investigation, dmesg and journalctl work as a pair: journalctl -b -1 -e gives you the userspace logs from the previous boot (persistent on disk), and dmesg gives you the current boot's kernel messages — but only if the box made it past the reboot, which the volatile ring buffer often does not. For durable kernel history across reboots, use journalctl -k -b -1 — it reads the same kernel feed but stores it persistently.

Note

journalctl --dmesg (or journalctl -k) is the journald-flavored view of the same kernel feed — same content, journalctl's filter language. Use dmesg when you want the raw current buffer fast; use journalctl -k when you want to query across boots or compose with other journal filters.

Gotchas

The buffer is fixed-size and lives in RAM. Old messages scroll off; everything is gone after reboot unless rsyslog or journald captured it. See the Warning above.
Plain dmesg shows seconds-since-boot. [1234567.890] is unreadable. Use -T every time.
-T can be slightly wrong across suspend/resume. The kernel stamps in monotonic time; the wall-clock conversion drifts on a laptop that slept. The order is always right; the absolute times may not be.
You may need to be root. On modern kernels with kernel.dmesg_restrict=1 (default on many distros), non-root users get Operation not permitted. sudo dmesg fixes it. Check with sysctl kernel.dmesg_restrict.
A line about your hardware isn't always a problem. Drivers chatter on startup and on every device event — ata1.00: configured for UDMA/133 is normal, not an error. Read -l err,warn if you only want the problems.
dmesg -c destroys evidence. Reading-and-clearing is occasionally useful (one-shot baselines), but on a production box you almost never want to throw away the buffer.
What's not here: logins, cron jobs, nginx errors, mysql slow queries, your own application logs — none of those touch the kernel, so they're not in the buffer. That's journalctl and the files under /var/log.

History & Philosophy

dmesg is one of the oldest commands in Unix — the name is short for "display message," and it's been in the system since the late 1970s, originally just reading /dev/kmem to find the kernel's boot messages. The implementation has changed many times (today it uses the klogctl(2) system call or reads /dev/kmsg), but the abstraction has never moved: the kernel talks to you in one place, and that place is the ring buffer. For nearly fifty years of Unix history, regardless of which init system was in fashion, which logger was loaded, or whether the box even had a userspace booted yet, the kernel has had a buffer with its boot story in it, and dmesg has been the way to read it.

The deeper idea, and the one that makes the whole logging landscape click: the boundary between kernel and userspace is also a logging boundary. Kernel events are noticed by code running in privileged mode where there is no stdout, no library, no syslog client — just printk() and a ring buffer in RAM. Userspace events are noticed by ordinary programs that can call logger, open a syslog socket, or write to a file. journalctl eventually unified both sides, by also slurping the kernel ring buffer over /dev/kmsg — but the buffer itself, and dmesg as its primary reader, sits below all of that as a kind of bedrock. Even when nothing else works, the kernel can still talk, and dmesg is how you listen.