Systemd 服务恢复剧本

当 systemd 服务“无声崩溃”时，问题出在哪？

某个服务在凌晨突然停止响应，用户反馈时只剩“没反应”这个线索。传统的排查手段往往陷入三个困境：

• 日志分散难溯源：服务崩溃日志可能散落在 /var/log/messages、journalctl -u xxx.service 以及应用自身日志中，手工拼接时间线成本极高。
• 依赖链断裂无迹可寻：某个底层服务升级后，上层服务突然启动失败，但 systemctl status 仅显示 “Failed” 状态，真实原因隐藏在依赖关系中。
• 资源限制未暴露根因：服务因内存超限被 OOM Killer 终止，但默认配置下 systemctl status 不会直接显示 cgroup 内存阈值。

这些问题的共同痛点是：故障现象与根因之间存在多层技术断层，需要工程师在日志、状态、配置之间反复跳转，耗时数小时甚至更久。

从日志到根因：剧本如何缩短排障路径

该技能围绕 systemd 原生接口构建了一套分层诊断流程，核心是通过技术手段逐步缩小问题范围。

第一步：快速锁定崩溃现场。利用 journalctl 的 --since 和 -u 参数快速过滤服务相关日志，例如 journalctl -u myservice --since "24 hours ago"。相比手动查看系统日志，能直接聚焦服务上下文，避免无关日志干扰。

第二步：状态与依赖的双重验证。通过 systemctl status 获取服务当前状态码（如 1/3/5），同时调用 systemd-analyze dot --type=service myservice 生成依赖关系图。例如当依赖图中出现 network-online.target 断链时，可快速定位网络服务未就绪导致的启动失败。

第三步：退出码与资源限制的深度解析。结合 systemctl show -p ExecStart myservice 获取原始启动命令，通过 dbus-send --system --print-reply --dest=org.freedesktop.systemd1 ... 查询进程的退出码与资源限制（如内存上限）。若退出码显示 137（SIGKILL），可进一步通过 cat /sys/fs/cgroup/memory/.../memory.max_usage_in_bytes 确认是否触发 cgroup 内存限制。

第四步：自动化恢复策略。根据诊断结果生成临时恢复命令，例如 systemctl restart myservice 配合 systemctl enable --now myservice 恢复服务运行，并通过 systemd-analyze verify myservice 验证配置有效性。

适用边界：哪些场景需要谨慎使用

该技能并非万能药，以下场景需注意：

• 非 systemd 原生环境：在容器化部署或使用其他 init 系统的环境中，依赖检查功能可能失效。
• 多服务级联故障：当故障涉及多个服务相互依赖时，需配合 systemd-analyze critical-chain 进一步分析。
• 第三方服务配置变更：如果服务依赖非标准路径（如通过 EnvironmentFile= 加载私有配置），需额外检查配置源。

根据用户反馈，该技能在“服务重启后异常”场景下表现出色，但在涉及动态资源调度（如 K8s 集成）或混合部署架构时，仍需结合其他工具补充分析。