技能介绍

问题：服务挂了，但没人说得清为什么

systemctl start 失败、进程在重启循环里反复横跳、systemctl status 只给出一句 failed 却没有任何有效线索——这类场景在运维现场并不少见。传统排查要手动翻 journalctl、逐行 grep，再打开 unit 文件逐行对照配置，往往半小时过去才定位到一个 Type=notify 配错，或者 After= 依赖顺序颠倒。

技能如何工作

这个技能把上述排查流程拆成三个可重复的步骤：

结构化日志提取：通过 journalctl -u <unit> -o json 拿到结构化 JSON 输出，而不是对纯文本做正则匹配，便于直接读取 EXIT_CODE、CODE_FILE 等关键字段。
单元属性核对：用 systemctl show <unit> 拉取实际生效的 unit 属性（如 ExecStart、Restart、TimeoutStopSec），与预期配置做比对。
配置与依赖校验：调用 systemd-analyze verify 检查 unit 文件的语法与引用错误，再用 systemd-analyze dot 生成依赖图，识别 ordering 问题。

能力边界与注意事项

它不是一个自动修复工具。诊断结果指向根因之后，修改 unit 文件、重启服务、处理文件权限或网络依赖仍然需要人工介入。systemd-analyze verify 对已加载的 unit 与磁盘上的文件可能给出不同结论；dot 输出的依赖图在复杂的 Wants / After 组合下需要人工判读。另外，journalctl 能查到的历史深度受 journald 的存储轮转策略限制，过早的记录可能已经不存在。