Linux查看开机日志及故障排查步骤

Linux系统启动故障排查需分层选用精准工具：journalctl -b 是查看本次完整启动日志的首选，结构清晰、时间准确、服务归属明确；dmesg 则专攻内核早期硬件与驱动问题，能捕获journald启动前的关键报错；而/var/log/下的传统文本日志仅作交叉验证之用。掌握 journalctl -b -p err 快速定位错误、dmesg -l err,warn 过滤真实告警、journalctl -b -1 回溯历史启动等核心技巧，可大幅避开无效搜索和误判陷阱——真正高效的排障，不在于看多少日志，而在于用对哪一层的哪一条命令。

直接看本次启动的完整日志用 journalctl -b

绝大多数现代 Linux（Ubuntu 22.04+、CentOS 7+、Debian 11+）都用 systemd，journalctl -b 就是查“这次开机从内核加载到桌面/服务就绪”的全部记录，不混入其他运行时日志。它比翻文件靠谱得多——因为 journal 是结构化存储，时间戳准、来源清、服务归属明确。

• journalctl -b 默认按时间正序输出，最新条目在最后；加 --no-pager 可避免卡在 less 里
• 想快速扫错误？用 journalctl -b -p err ——只显示 err 及更严重级别（crit/alert/emerg），跳过大量 info 级干扰
• 别用 journalctl | grep failed：journalctl 自带过滤，管道进 grep 会丢失优先级、服务名等元数据，且可能截断长行
• 如果系统刚崩了进不去图形界面，SSH 也连不上，先别急着重装——只要还能进单用户模式或 recovery shell，journalctl -b 通常仍可用（journald 默认内存缓存，但若启用了持久化，日志已落盘到 /var/log/journal/）

硬件/驱动问题优先查 dmesg，不是 journalctl

dmesg 输出的是内核环形缓冲区原始内容，从 GRUB 把控制权交给 kernel 的第一行开始，包括 CPU 检测、内存映射、PCIe 设备枚举、驱动 probe 成败——这些信息 journalctl -b 会收录，但会被格式化、截断，甚至因 journald 启动晚而漏掉 early boot 阶段。

• dmesg -l err,warn 比 dmesg | grep -i "error" 更可靠：前者按内核定义的 log level 过滤，后者可能匹配到正常字符串（比如某模块名含 “error”）
• dmesg -T 加人类可读时间戳，但注意：该时间基于系统当前时钟，若 RTC 不准或 NTP 没同步，早期日志时间可能偏移；诊断冷启动失败时，优先用默认无 -T 的输出
• 如果 dmesg 输出为空或极短，说明内核可能根本没跑起来（如 initramfs 解包失败、根文件系统找不到），这时要回头查 GRUB 参数或 initrd 内容，而不是继续翻日志
• dmesg 缓冲区大小有限（通常 64K~1M），老消息会被覆盖；若需长期保留，得靠 systemd-journald 持久化或手动执行 dmesg > /tmp/dmesg.boot 抓快照

/var/log/boot.log 和 /var/log/messages 只作辅助验证

这些文本日志是传统 SysVinit 遗留机制，现在多数发行版已不主动写入它们——除非你手动启用了 rsyslog 转发或禁用了 journald。它们的价值在于交叉验证：比如 journalctl -b 显示某服务启动超时，而 /var/log/messages 里同一时间点有 “SELinux denied” 记录，那问题大概率不在服务本身。

• /var/log/boot.log 在 CentOS/RHEL 系统中可能有内容，但在 Ubuntu/Debian 上常为空或仅含 minimal 初始化信息；别把它当主依据
• /var/log/messages（RHEL 系）或 /var/log/syslog（Debian 系）是 syslog 守护进程汇总的日志，但 systemd 下很多消息根本不会走这路，尤其 early boot 阶段
• 用 tail -n 50 /var/log/messages 快速瞄一眼没问题，但若发现关键报错不在里面，别怀疑自己漏看了——很可能它压根就没被 syslog 接收
• 如果 journalctl 和 dmesg 都没线索，再检查 /var/log/journal/ 目录是否存在、是否可读；若为空，确认 Storage=persistent 是否在 /etc/systemd/journald.conf 中启用

查历史启动（比如上一次成功/失败）必须用 -b -1，不能靠文件修改时间

系统重启后，/var/log/ 下的文本日志文件不会自动按启动会话切分，而 journal 会为每次 boot 分配唯一 ID。所以想对比“这次崩了 vs 上次好好的”，journalctl -b -1 是唯一可靠方式。

• journalctl -b -1 查上一次；journalctl -b -2 查上上次……最多支持到 -b -10 左右，具体取决于 SystemMaxUse 配置
• 别用 ls -lt /var/log/ 看 messages 文件时间戳来判断“上次启动”——日志轮转（logrotate）会改时间，且多会话下文件内容是混在一起的
• 如果 journalctl -b -1 报错 “No such boot ID”，说明该次启动日志未持久化保存，要么 journald 没配置持久化，要么那次启动时磁盘已满或 journal 目录权限异常
• 需要导出某次启动日志做离线分析？用 journalctl -b -1 --all --no-pager > boot-previous.log；--all 确保不丢二进制字段（如堆栈），--no-pager 避免分页器污染输出

真正卡住的时候，90% 的人会反复刷 journalctl -b 却忽略 dmesg -l err,warn 里的硬件报错，或者把空的 /var/log/boot.log 当成证据。启动日志不是“看全了就行”，而是要分层：内核层（dmesg）、初始化层（journalctl -b）、服务层（journalctl -u xxx），每层失效点不同，工具也不同。

终于介绍完啦！小伙伴们，这篇关于《Linux查看开机日志及故障排查步骤》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！