关键不是看“花了多久”，而是弄清“卡在哪一步、等谁、报什么错”：journalctl还原时间线和失败上下文，systemd-analyze排序耗时，二者结合才能定位根因；需关注starting到timeout间隔、result类型、依赖单元状态及服务内部首条错误日志。
排查服务启动超时，关键不是看“花了多久”，而是弄清“卡在哪一步、等谁、报什么错”。journalctl 不算耗时，但能精准还原时间线和失败上下文，配合 systemd-analyze 的耗时排序，才能定位根因。
确认服务实际启动时间线
先用带毫秒时间戳的格式查看本次启动中该服务的完整过程：
- journalctl -b -u servicename.service --no-pager -o short-iso
你会看到类似：
- 2026-07-07 05:10:22.123456 hostname systemd[1]: Starting nginx.service
- 2026-07-07 05:10:28.678901 hostname systemd[1]: nginx.service: Start operation timed out. Terminating.
- 2026-07-07 05:10:28.789012 hostname systemd[1]: nginx.service: Failed with result 'timeout'.
从 Starting 到 timeout 这段间隔，就是真实卡顿区间。注意末尾的 result 类型（timeout / exit-code / signal），它直接说明失败性质。
检查依赖阻塞点
很多超时本质是等不到前置条件就绪。重点查三类依赖单元：
- network-online.target：运行 journalctl -b | grep "network-online.target"，看 NetworkManager-wait-online.service 是否超时或失败
- local-fs.target / remote-fs.target：查挂载相关日志，如 journalctl -b | grep "\.mount" | grep -i "activating\|timeout\|failed"
- 其他明确依赖的服务：用 systemctl list-dependencies servicename.service 查依赖树，再针对性查对应单元日志
定位具体失败动作
服务内部执行阶段出错，日志通常紧随 Starting 后出现。重点关注：
- 配置加载失败：如 nginx: [emerg] invalid number of arguments in "listen" directive
- 资源不可用：如 Failed to bind to port 80: Address already in use 或 Cannot open /etc/ssl/private/key.pem: Permission denied
- 外部依赖无响应：如 Failed to connect to database: Connection refused
- 挂载点缺失或延迟：如 mount: /mnt/data: special device UUID=xxx does not exist
这些错误往往出现在 Starting... 之后、Started... 之前的第一处非 info 级输出。
排除日志缺失干扰
如果 journalctl -u servicename 完全为空，说明服务根本没走到执行阶段。此时需检查：
- unit 文件是否被识别：systemctl list-unit-files | grep servicename
- 语法是否通过预检：systemd-analyze verify servicename.service
- ExecStart 指向路径是否存在且可执行：ls -l $(systemctl show -p ExecStart servicename.service | cut -d= -f2)
- Type 配置是否匹配行为：例如 Type=simple 却设了 RemainAfterExit=yes，可能引发状态误判
