Linux系统日志与dmesg使用技巧

Linux系统故障排查中，dmesg是捕获内核级硬件异常（如硬盘掉线、PCIe错误、USB断连、OOM Killer触发等）的第一手关键工具，但其默认行为易导致重要线索被环形缓冲区覆盖或淹没在海量日志中；掌握dmesg -w实时监听、-T精准对时、-H高亮分页等技巧可大幅提升响应效率，同时需结合journalctl -k持久化日志、lsblk -S/nvme list等硬件定位命令，并聚焦error/failed/timeout、硬件地址（如PCI ID）、重复刷屏等有效信号，避开ACPI等干扰信息——真正高效的日志分析，不是看全，而是快速锁定内核告诉你的“真相”。

怎么看 dmesg 的实时输出

系统刚出问题时，dmesg 最可能留下第一手线索，但默认输出是全部历史缓存，滚动太快看不清关键行。别直接敲 dmesg 回车完事。

• 加 -H（human-readable）分页高亮： dmesg -H，按空格翻页，/usb 可搜索
• 加 -T 显示本地时间（不是自启动秒数）： dmesg -T | tail -20，方便和你操作时间对齐
• 想持续观察新日志？用 dmesg -w —— 它会阻塞等待新内核消息，Ctrl+C 退出
• -w 在某些旧内核（如 CentOS 7 默认的 3.10）不支持，此时改用 watch -n 1 'dmesg | tail -10'

为什么 dmesg 看不到最近的硬件报错

内核环形缓冲区大小有限，默认通常 64K～256K，大量日志一刷就滚掉。不是没发生，是被覆盖了。

• 查当前缓冲区大小： cat /proc/sys/kernel/dmesg_restrict（0=普通用户可读，1=仅 root）
• 增大缓冲区需改内核参数：临时生效用 sudo sysctl -w kernel.dmesg_restrict=0；持久化要写进 /etc/sysctl.conf
• 更稳妥的做法是让日志落地：rsyslog 或 journald 会自动捕获 dmesg 输出，查 journalctl -k 更可靠
• 注意：dmesg 不记录用户态进程崩溃，只管内核态——比如硬盘掉线、PCIe link down、OOM killer 日志在这里，但 Python 段错误不在

dmesg 报错里哪些字段真正该盯住

满屏的 [ 2.123456] ata1: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen 类信息，90% 是干扰项。重点扫三类模式：

• 含 error、failed、timeout、reset 的行：比如 nvme 0000:01:00.0: I/O 32 QID 0 timeout
• 含硬件地址的异常：如 PCIe Bus Error: severity=Corrected 后跟 device [8086:1e1a]，可反查芯片型号
• 连续重复出现的同一行（尤其带递增计数）：比如 usb 1-1.2: device not accepting address 5, error -71 刷屏，基本确定 USB 设备或 hub 故障
• 别被 ACPI Error 吓住——很多笔记本 BIOS 有兼容性 bug，只要没伴随功能异常（如风扇失控、休眠失败），通常可忽略

怎么把 dmesg 和具体硬件故障对应上

看到 dmesg 说硬盘出错，但不确定是哪块盘？不能靠猜设备名（sda 可能每次启动变）。

• 先用 lsblk -S 查物理设备模型和序列号，再用 dmesg | grep -i "sd[a-z].*ata\|nvme" 找关联日志
• 对 NVMe 盘，sudo nvme list 和 dmesg | grep nvme 输出里的 0000:01:00.0 PCI 地址必须一致
• USB 设备断连时，dmesg 会打出 usb 2-1.3: new high-speed USB device number 15 using xhci_hcd，其中 2-1.3 是总线-端口路径，拔插时对比这个编号最准
• 如果 dmesg 提到 EDID 错误，大概率是显示器线材或接口接触不良，换根线比调驱动更有效

内核日志不是万能索引，它只记录“内核看到了什么”。有些硬件问题（比如 SSD 主控固件静默丢数据）根本不会触发 dmesg 输出，得靠 smartctl 或厂商工具交叉验证。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Linux系统日志与dmesg使用技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。