systemd 服务启动失败排查

目标

在不盲目重启、不直接改软件包单元文件的前提下，确认服务的加载状态、失败结果、日志时间线和实际配置；处理根因后只恢复一次并验证。

前置条件

• 系统使用 systemd，并已确认准确的 .service 单元名。
• 有终端访问；读取受限日志或重启系统服务时需要管理员权限。
• 排查 SSH、网络或存储服务时，准备本地控制台或第二条会话，防止修改后失联。
• 如果刚改过应用配置，保留修改前的备份和该应用官方的配置校验方法。

操作步骤

1. 设置并核对目标，不要只凭相似的进程名：

   unit=ssh.service
   systemctl status --no-pager --full "$unit"
   systemctl show --property=LoadState,ActiveState,SubState,Result "$unit"

2. 保存当前启动中最近的服务日志。公开或提交日志前先脱敏：

   journalctl --boot=0 --unit="$unit" --lines=100 --no-pager

3. 查看 systemd 实际加载的主文件和 drop-in，查找错误路径、用户、依赖或启动命令：

   systemctl cat "$unit"
   systemctl list-dependencies "$unit"

4. 根据日志中的第一条直接错误处理根因。应用配置只能用该应用官方提供的校验命令验证；不要把“重启成功”当作配置正确的证明。

5. 只有在根因已处理、影响范围可接受时，执行一次恢复：

   # 仅当修改过 systemd 单元或 drop-in 时需要
   sudo systemctl daemon-reload
   
   sudo systemctl restart "$unit"

验证

systemctl is-active "$unit"
systemctl show --property=ActiveState,SubState,Result "$unit"
journalctl --boot=0 --unit="$unit" --lines=30 --no-pager

除了 active，还必须执行服务自身的业务验证，例如本机访问监听端口、读取传感器或完成一次无副作用请求。

回滚或清理

只读排查无需回滚。若本次修改配置后服务变差：

1. 使用本地控制台恢复已备份的上一版配置或移除本次新增的 drop-in。
2. 若改动涉及单元定义，运行 sudo systemctl daemon-reload。
3. 运行 sudo systemctl restart "$unit"，再重复验证。

重启会中断旧进程，无法恢复其内存状态；关键服务应先按应用自己的备份和恢复规范操作。

故障排查

现象	先检查	处理原则
Unit ... not found	LoadState、单元名和软件包是否存在	不要猜名称；从发行版软件包或 list-unit-files 核对。
status=203/EXEC	ExecStart 路径、权限、解释器	核对实际文件和执行权限，不用 chmod 777。
start request repeated too quickly	更早的首次失败日志	先修根因，再重置失败状态或重启。
服务 active 但功能不可用	监听地址、依赖和应用日志	做业务层验证，不能只看 systemd 状态。
重启后远程连接中断	是否操作网络或 SSH 单元	停止远程试验，转到本地控制台恢复。

相关内容

• systemctl
• journalctl
• systemd 单元与服务状态
• 进程、PID 与信号