技能介绍

要解决的问题

systemd 服务失败时，排障往往散落在多处：systemctl status 给出的状态可能过于概括，journalctl 的日志量很大且包含噪声，unit 依赖冲突、ExecStart 命令退出码异常、文件句柄或进程数限制触发 OOM 等问题，常常需要分别手工排查。结果是线索容易遗漏，结论也难形成可复现的修复建议。

核心能力与工作方式

该技能面向 失败的 systemd unit，主要使用 journalctl、systemctl 和 systemd D-Bus API 三类接口来收集诊断信息，并在分析后生成修复建议：

状态与日志聚合：通过 systemctl status 等命令确认服务当前状态，再借助 journalctl 按时间线查看启动日志和运行期错误，减少人工翻找大量日志的成本。
依赖关系分析：检查 unit 之间的依赖、加载与启动顺序，定位因前置 unit 未就绪、依赖冲突或资源争用导致的启动失败。
ExecStart 失败定位：围绕 ExecStart 配置执行结果进行分析，包括命令是否以非零码退出、参数是否正确、工作目录或环境变量是否满足运行前提。
资源限制检查：结合 unit 或 systemd 层面的资源约束进行分析，识别因内存、进程数、打开文件数等限制触发的启动异常。
修复建议输出：在综合状态、日志、依赖和资源信息后，给出针对 unit 配置或运行条件的修复方向，而不是只返回原始报错。

适用边界与注意点

该技能的价值在于把常见 systemd 排障入口统一起来，但最终修复仍取决于具体 unit 配置、主机环境和业务代码行为。使用时建议先在测试环境验证：确认目标服务可安全重启或变更配置，保留变更前 unit 文件与日志快照，并在敏感或生产流程前充分审查上游项目。当前资料未提供可自动提取的安装与使用说明，因此执行前应先检查来源和项目说明。