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
真实排查中，journalctl -b 和 dmesg 必须一起看——前者告诉你“哪个服务没起来”，后者告诉你“为什么起不来”。/var/log/ 下的文件只是辅助验证，不是主路径。
