journalctl 不直接计算耗时，但通过 -b --no-pager -o short-iso 查看本次启动时间戳日志，可精确定位服务起止时刻、失败原因及依赖阻塞点，如 networkmanager-wait-online.service 超时或 .mount 单元等待设备不可达，从而验证并深挖 systemd-analyze 发现的瓶颈根因。
journalctl 本身不直接计算耗时，但它能提供精确时间戳和完整事件链，是验证、交叉比对和定位耗时根因的关键依据。真正做耗时分析的是 systemd-analyze，而 journalctl 负责告诉你“那个慢的服务，到底卡在了哪一步、报了什么错、等了谁”。
要通过 journalctl 辅助完成启动耗时分析，重点不是看总时间，而是结合时间轴，确认关键单元的启动起止时刻、失败原因、依赖阻塞点。
查看本次启动中各服务的实际启动时间线
运行命令：
journalctl -b --no-pager -o short-iso
-
-b：只查本次启动（boot）的日志 -
--no-pager：避免分页截断，方便滚动查看 -
-o short-iso：用 ISO 格式显示时间（精确到毫秒），便于比对先后顺序
你会看到类似这样的条目：
2026-06-17 08:12:34.123456 hostname systemd[1]: Starting NetworkManager.service... 2026-06-17 08:12:34.678901 hostname NetworkManager[1234]: <info> startup complete 2026-06-17 08:12:35.234567 hostname systemd[1]: Started NetworkManager.service.</info>
→ 从 Starting 到 Started 耗时约 1.1 秒，和 systemd-analyze blame 中该服务的耗时基本一致。
定位高耗时单元的具体卡点
假设 systemd-analyze blame 显示 docker.service 耗时 8.2s，但你不确定它为何慢：
journalctl -b -u docker.service --no-pager
常见线索包括：
- 日志中出现
Waiting for network-online.target→ 说明被NetworkManager-wait-online.service拖住 - 出现
failed to mount /var/lib/docker或device not found→ 可能挂载点配置错误或磁盘未就绪 - 有
level=error msg="failed to start daemon"→ 配置文件语法错误或端口冲突
再配合：
journalctl -b | grep -E "(docker|NetworkManager-wait-online|network-online.target)" --no-pager
就能看出依赖关系是否断裂、等待是否超时。
检查挂载失败或卡住的 .mount 单元
很多启动慢实际源于 /etc/fstab 中一个失效的 NFS 或 UUID 错误的磁盘：
journalctl -b | grep "\.mount" --no-pager | grep -E "(activating|failed|timeout)"
例如输出：
Jun 17 08:12:22 host systemd[1]: dev-disk-by\x2duuid-xxxxx.mount: Job dev-disk-by\x2duuid-xxxxx.mount/start timed out
接着查具体单元：
systemctl status dev-disk-by\x2duuid-xxxxx.mount journalctl -b -u dev-disk-by\x2duuid-xxxxx.mount
日志里通常会明确写：“NFS server not responding” 或 “device /dev/sdb1 does not exist”。
关联关键路径中的阻塞点
systemd-analyze critical-chain 给出的是理论依赖链，而 journalctl 告诉你实际发生了什么：
比如 critical-chain 显示：
graphical.target → multi-user.target → docker.service → network-online.target
那就查：
journalctl -b -u network-online.target --no-pager journalctl -b -u NetworkManager-wait-online.service --no-pager
如果发现 NetworkManager-wait-online.service 等了 30 秒才超时退出，日志里大概率有：
Timed out waiting for devices to become available: 30s
→ 这说明 DHCP 获取 IPv4 失败，或系统默认等待 IPv6 RA（可禁用 RA 或调低超时）。
不复杂但容易忽略
