Linux怎么查看系统启动日志

journalctl -b 是查看本次启动日志的唯一可靠方式，它能完整覆盖从内核加载到用户空间服务就绪的全过程，而 /var/log/messages 等传统日志在现代 systemd 系统中常为空或缺失关键信息。

journalctl -b 是查看本次启动日志的唯一可靠方式

直接读取 /var/log/messages 或使用 tail /var/log/boot.log 命令，在现代的systemd系统中，很可能会遗漏关键信息。原因在于，许多服务（比如 sshd.service、dbus.service）仅向journald发送日志，而不会写入磁盘。只有通过 journalctl -b 命令，才能获取到从内核加载到用户空间服务就绪的完整链路信息。

常见错误现象：journalctl 报错 No journal files were found，说明 journald 没启用持久化，重启后日志已丢；此时 journalctl --list-boots 会返回空。

• 先确认是否启用持久化：sudo mkdir -p /var/log/journal && sudo chown root:systemd-journal /var/log/journal && sudo systemctl restart systemd-journald
• -b 默认指最新一次启动，-b -1 是上一次，-b -2 是再上一次，依此类推
• 加 -n 100 限制行数，避免刷屏；-n 不是“最近 100 秒”，而是“最后 100 行”

dmesg 是诊断硬件/驱动问题不可替代的入口

dmesg 输出的是内核环形缓冲区原始内容，不受 systemd 是否崩溃影响，尤其适合查显卡初始化失败、USB 设备未识别、内存映射冲突等底层问题。

容易踩的坑：默认输出不含时间戳，且滚动太快；dmesg | less 无法高亮搜索，dmesg -T 加了时间但可能因系统时钟未同步导致时间错乱。

• 用 dmesg -l err,warn 只看错误和警告，比全文扫更高效
• 保存快照用于离线分析：dmesg > /tmp/dmesg.boot
• 实时监控新消息：dmesg -w，但注意它不会回放历史，只捕获后续内核事件

别忽略 /var/log/ 下的 boot.log 和 messages（仅限特定场景）

CentOS 7、RHEL 7以及部分禁用了journald的嵌入式系统，依旧依赖传统的日志落盘方式。在这种情况下，/var/log/boot.log会记录init进程拉起服务的顺序，/var/log/messages则包含早期systemd单元启动的摘要信息。不过，这些文件在Ubuntu 22.04+或Fedora 38+上基本为空，或者仅存有备份。

使用前提：确认 rsyslog 或 syslog-ng 正在运行（systemctl is-active rsyslog），且配置中明确启用了 boot 相关日志写入。

• grep "Starting" /var/log/boot.log 可快速定位服务启动起点
• tail -50 /var/log/messages | grep -i "failed|timeout" 能补全 journalctl -b -p err 没覆盖到的旧服务行为
• Debian/Ubuntu 系统请优先查 /var/log/syslog，而非 messages

按服务查启动失败原因必须带 .service 后缀

查某个服务是否启动成功，不能只写 journalctl -u nginx，必须写 journalctl -u nginx.service，否则报 No journal files were found。这是 unit 名称规范，不是可选项。

另一个常见盲区：有些服务由 socket 激活（如 sshd.socket），但连接处理日志实际记在 sshd.service 里；查 socket 单元只能看到监听端口行为，看不到认证失败细节。

• 查失败启动：journalctl --failed 列出所有最近失败的 unit
• 查某服务本次启动全过程：journalctl -u nginx.service -b
• 想看启动耗时瓶颈：systemd-analyze blame 或 systemd-analyze critical-chain nginx.service