The Linux kernel logs hardware detection, driver messages and serious events, like processes killed for lack of memory, disk errors and crashing programs, into a ring buffer. dmesg prints it. When something dies without explanation in the application logs, dmesg often has the answer.

Basic use

sudo dmesg

Most distributions restrict dmesg to root (kernel.dmesg_restrict=1), so use sudo.

Readable timestamps and colours:

sudo dmesg -T            # human-readable time instead of seconds since boot
sudo dmesg -H            # paged, coloured, relative times
sudo dmesg -T | tail -50

-T timestamps can drift slightly if the system has been suspended. That rarely matters on servers.

Follow new messages

sudo dmesg -wT

Leave it running while you reproduce a problem, such as plugging in a disk, loading a module or starting a service that crashes.

Filter by level or facility

sudo dmesg -T --level=err,warn
sudo dmesg -T --level=emerg,alert,crit,err
sudo dmesg -T -f kern

What to look for

Out of memory (OOM) kills

sudo dmesg -T | grep -iE 'out of memory|oom-kill|killed process'
[Wed Oct 14 03:12:44 2026] Out of memory: Killed process 2311 (mysqld) total-vm:2516432kB, anon-rss:1621340kB …

The kernel ran out of RAM and swap and killed a process, often the biggest one: MySQL, Java or Node. This explains “MySQL stopped by itself”. Reduce memory use, add swap as a buffer, or move to a plan with more RAM. See OOM killer.

Disk and filesystem errors

sudo dmesg -T | grep -iE 'i/o error|ext4-fs error|xfs.*error|blk_update_request|medium error'
blk_update_request: I/O error, dev sdb, sector 123456 …
EXT4-fs error (device vda1): ext4_lookup:1601: inode #…
EXT4-fs (vda1): Remounting filesystem read-only

I/O errors on a dedicated server often mean a failing drive. Check SMART (smartctl -a /dev/sdb) and RAID status (cat /proc/mdstat). See software RAID. A filesystem remounted read-only needs an fsck. On a VPS, contact support if storage errors appear.

Segfaults

sudo dmesg -T | grep -i segfault
php-fpm8.3[4412]: segfault at 0 ip 00007f… error 4 in opcache.so …

A program crashed. The library name (here opcache.so) hints at the cause: a buggy extension, a module compiled for another version, or occasionally bad RAM on physical hardware.

Network and firewall

sudo dmesg -T | grep -iE 'link is (up|down)|nf_conntrack: table full|UFW BLOCK'
  • nf_conntrack: table full, dropping packet — under heavy traffic or an attack, the connection-tracking table filled up. Raise net.netfilter.nf_conntrack_max and find the cause. See sysctl tuning.
  • UFW BLOCK — firewall log lines (if logging is on). They’re useful for checking what’s being blocked.

Hardware detection

sudo dmesg -T | grep -iE 'vd[a-z]|sd[a-z]|nvme' | tail      # newly attached disks
sudo dmesg -T | grep -i 'eth\|ens'                          # network interfaces

Hung tasks

INFO: task mysqld:1234 blocked for more than 120 seconds.

A process was stuck on I/O for minutes. That points to severe storage latency or a dead NFS mount.

The buffer is limited and resets at boot

The ring buffer holds a limited amount and is cleared on reboot. For older messages, or messages from before a crash or reboot, use the journal:

journalctl -k                    # kernel messages, this boot
journalctl -k -b -1              # kernel messages from the previous boot
journalctl -k --since "2 hours ago" -p err

journalctl -b -1 keeps working only if the journal is persistent (/var/log/journal exists). See journalctl.

Clear the buffer

sudo dmesg -C        # clear (useful before reproducing an issue)

Quick reference

Task Command
Readable times sudo dmesg -T
Follow sudo dmesg -wT
Errors only sudo dmesg -T --level=err,crit,alert,emerg
OOM kills dmesg -T | grep -i 'killed process'
Disk errors dmesg -T | grep -i 'i/o error'
Segfaults dmesg -T | grep -i segfault
Previous boot journalctl -k -b -1

Related: uname and kernel version and disk full troubleshooting.

  • Linux
  • Troubleshooting
  • Logs