systemd RestartMode 怎么减少依赖单元连锁失败

如果一个 systemd 服务只是短暂失败，并且已经配置自动重启，可以把 RestartMode 设为 direct。这样服务在自动重启时会直接回到 activating 状态，不再经过对外可见的 failed/inactive 中间状态，依赖单元也不会收到这次临时失败通知，从而减少本可自愈的小故障引发连锁停止或失败。

这项配置只隔离“自动重启期间的短暂失败”。如果重启次数触发启动限速、服务无法恢复，或者依赖关系本身要求严格联动，最终失败仍会暴露，不能把 RestartMode=direct 当成故障屏蔽器。

官方手册：https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html

RestartMode=direct 从 systemd 254 开始提供。部署前先确认目标发行版实际使用的 systemd 版本，而不是只看发行版名称。

direct 模式到底改变了什么

默认的 RestartMode=normal 会让一次失败先经过 failed 或 inactive，再进入自动重启。这个短暂状态可能被依赖关系、监控规则或失败处理单元观察到。direct 则在符合 Restart= 策略时直接进入 activating，让可恢复故障留在当前服务的恢复边界内。

因此，direct 适合“进程偶尔退出，但很快重新启动后仍能继续提供同一能力”的服务。例如短暂网络抖动导致连接代理退出，而上层应用不需要因一次可恢复退出立刻停止。若服务失败会破坏共享状态、产生不兼容输出或要求依赖方立即撤离，就不应隐藏这个中间状态。

用 drop-in 配置 RestartMode=direct

建议用 drop-in 覆盖，而不是直接编辑发行版安装到 /usr/lib/systemd/system 的单元文件。假设需要保护的是 backend.service，可以执行：

# 创建或编辑该服务的本地覆盖配置
sudo systemctl edit backend.service

在打开的 drop-in 中写入：

[Service]
# 仅在非正常退出、信号、超时等失败条件下自动重启
Restart=on-failure

# 给资源释放和外部依赖恢复留出短暂间隔
RestartSec=2s

# 自动重启时跳过 failed/inactive 中间状态
RestartMode=direct

保存后重新加载单元定义，再重启一次服务使配置进入当前运行实例：

# 让 systemd 重新读取单元与 drop-in
sudo systemctl daemon-reload

# 主动重启以应用本次配置修改
sudo systemctl restart backend.service

# 查看合并后的关键属性，确认没有写错节名
systemctl show backend.service -p Restart -p RestartUSec -p RestartMode

RestartMode 必须放在 [Service] 段，并且只有搭配会触发自动恢复的 Restart= 策略才有意义。它不会把 Restart=no 变成自动重启，也不会改变手工执行 systemctl stop 的意图。

依赖关系也要匹配真实故障语义

RestartMode 解决的是“一个可恢复服务在自动重启时是否把临时失败暴露出去”，它不能替代正确的依赖建模。上层服务只是希望后端尽量可用时，通常优先考虑 Wants= 配合 After=；确实要求启动事务一起成功时，再使用 Requires=；运行期间必须与对方生死绑定时，才考虑更强的 BindsTo= 配合 After=。

例如，上层应用只需要在启动时拉起 backend.service，但后端短暂重启时仍能排队或重连，可以使用较弱依赖：

[Unit]
# 启动应用时一并拉起后端，但后端失败不直接判定应用启动事务失败
Wants=backend.service

# 只负责启动顺序，不额外加强失败传播
After=backend.service

如果改成 BindsTo=backend.service 并配合 After=，含义是上层单元严格要求后端保持 active。此时，后端无法恢复后的 inactive/failed 应当让上层停止；direct 只能避免自动重启途中暴露短暂状态，不能取消这种最终约束。

别忽略启动限速和失败通知

自动重启仍受 StartLimitIntervalSec= 与 StartLimitBurst= 限制。若服务在短时间内持续崩溃，达到限速后 systemd 会停止继续尝试，服务最终进入失败状态。可以在 [Unit] 段明确窗口和次数，让恢复策略可预期：

[Unit]
# 在 60 秒统计窗口内限制启动次数
StartLimitIntervalSec=60s

# 超过 5 次后停止继续自动拉起
StartLimitBurst=5

[Service]
# 失败时自动重启，并隔离可恢复的中间状态
Restart=on-failure
RestartSec=2s
RestartMode=direct

另一个关键边界是：direct 模式在自动重启时跳过 OnSuccess= 和 OnFailure=。如果告警、故障采集或自动回滚依赖这些单元，就不要直接切换；可以把每次退出都必须执行的清理和轻量记录放在 ExecStopPost=，因为它在 direct 模式下仍会运行。最终不可恢复失败的告警则应结合启动限速后的状态、日志或独立监控来设计。

配置前后的判断清单

• 确认 systemd 版本不低于 254，并确认目标服务确实配置了 Restart 策略。
• 确认短暂重启期间，上层单元能够等待、重连或降级，而不是必须立即退出。
• 检查是否依赖 OnFailure 或 OnSuccess 触发告警与修复；direct 会跳过它们。
• 保留合理的 RestartSec 和启动限速，避免崩溃循环持续占用资源。
• 重新审视 Wants、Requires、BindsTo 与 After，确保依赖强度符合业务语义。

相关问题

RestartMode=direct 会让 systemctl status 永远看不到失败吗？ 不会。它只跳过可自动重启期间的 failed/inactive 中间状态；达到启动限速或没有匹配 Restart 策略时，最终失败仍会显示。

只设置 RestartMode=direct，不设置 Restart 可以吗？ 配置可以被解析，但没有自动重启就没有 direct 模式要处理的恢复过程，实际达不到目标。

direct 能阻止 BindsTo 传播最终失败吗？ 不能。它减少的是可恢复重启过程中的临时失败通知，无法改变强依赖对最终 inactive/failed 状态的约束。

为什么切换后 OnFailure 没执行？ 这是 direct 模式的明确语义：自动重启期间跳过 OnSuccess 和 OnFailure；需要每次停止都执行的动作应评估 ExecStopPost 或外部监控。