Linux怎么查看连接分配失败的详细日志

dmesg -L 能显示资源分配失败，需配合 grep 过滤关键词；-H 选项根本不存在，真实可用参数是 -L（等价 --color=always）结合 -w、--time-format=iso 等，并用正则匹配 fail/alloc/reserve/irq/dma/bar/iommu 等底层资源错误模式。

dmesg -L 不能显示资源分配失败？先确认真实可用参数

Linux的dmesg命令里，压根儿就没有-H这个选项哦！它可不是拼写错误，而是本来就不存在。你看到的dmesg -H，很可能是把journalctl -H（这个也不存在）或者ls -h这类命令给记混啦。那真正能开启彩色显示、提升可读性，并且聚焦在“连接/资源分配失败”的组合是什么呢？是dmesg -L（这和--color=always是等价的哦），再配合grep来过滤关键词。

运行 dmesg -L | head -3，如果看到带颜色的时间戳和日志级别（比如红色的 kern.warn），说明颜色已生效；若全是白字，说明终端不支持 ANSI 色彩或 less 未加 -R 参数。

过滤“连接分配失败”类内核日志的关键词模式

内核中所谓“连接分配失败”，实际多表现为底层资源申请失败，比如 PCI BAR 分配、DMA 映射、IRQ 绑定、IOMMU 域创建、内存页分配等。直接搜 “connection failed” 几乎找不到结果，必须用更底层的关键词：

• fail、failed、cannot assign、can't assign
• alloc、allocate、page allocation failure
• reserve、no memory、out of memory
• irq、dma_map_single、iommu、bar、PCI.*BAR

推荐一次性执行：
dmesg -L | grep -i -E "(fail|alloc|reserve|irq|dma|bar|iommu|no memory|out of)"
注意：-i 忽略大小写，-E 启用扩展正则，避免漏掉 __alloc_pages_slowpath 这类函数名。

实时监控新出现的资源分配失败日志

仅看历史日志不够——很多资源问题发生在设备热插拔、驱动重载或服务启动后。要用 -w 持续监听，并确保 grep 行缓冲生效，否则颜色会丢失：

• dmesg -L -w | grep --line-buffered -i -E "(fail|alloc|reserve|irq|dma)"
• 如果输出卡顿或无颜色，改用：stdbuf -oL dmesg -L -w | grep --line-buffered -i "fail"
• 想高亮更丰富？装 ccze：dmesg | ccze -A | less -R（-A 强制 ANSI 输出，less -R 渲染颜色）

注意：dmesg -w 依赖内核环缓冲区，重启后旧日志清空；早期启动阶段的问题（如 ACPI IRQ 分配失败）可能已被覆盖，这时要结合 /var/log/kern.log 或 journalctl -k 回溯。

为什么 /var/log/messages 里找不到这些失败？

因为大多数资源分配失败是内核直接打印到 ring buffer 的，**不会自动转发到 syslog**。除非 rsyslog 或 systemd-journald 明确配置了 kern.* 转发规则，否则 /var/log/messages 或 /var/log/syslog 里基本没有这类日志。

验证方法：
dmesg | grep -i "BAR.*can't assign" 能看到，但 grep -i "BAR" /var/log/messages 返回空 —— 这就是典型表现。

所以别在 /var/log/ 下盲目翻文件；优先用 dmesg -L + 关键词过滤，再辅以 journalctl -k（它读取的是 journald 收集的内核日志，可靠性取决于是否启用持久化存储）。

有个容易被忽视的要点：dmesg默认只展示ring buffer中的剩余部分，早期启动失败的信息可能已经被覆盖；而 journalctl -k是否包含完整记录，取决于 /etc/systemd/journald.conf 中的 Storage=是否设置为 persistent——默认情况下是未开启的。