systemd-resolved.service实验实战3

Systemd 设计模式：CrashGuard (防止无限重启)

痛点 (The Problem):

你给服务设置了 Restart=always，但程序有 Bug，启动后 1 秒即崩。
后果：Systemd 陷入死循环（重启风暴），CPU 飙升 100%，日志塞满磁盘，甚至导致无法 SSH 登录。

解法 (The Solution):

不要无脑重启。限制频率 ，并在彻底失败后触发备用方案。

1. 核心机制 (背下这 3 个参数)

• StartLimitIntervalSec: 时间窗口 (例如 10秒)。
• StartLimitBurst: 允许崩溃的最大次数 (例如 3次)。
• OnFailure: 当达到限制后，Systemd 放弃重启，转而启动的服务。

---

2. 实战配置

服务 A：不稳定的主程序 (受害者)

/etc/systemd/system/unstable-app.service

[Unit]
Description=My Buggy App
# 【规则】如果在 10秒 内崩溃超过 3次...
StartLimitIntervalSec=10
StartLimitBurst=3
# 【动作】彻底停止尝试，并启动下面这个服务：
OnFailure=safe-mode.service

[Service]
# 模拟崩溃 (1秒后退出)
ExecStart=/bin/bash -c "sleep 1 && exit 1"
Restart=always
RestartSec=1

服务 B：安全模式 (救世主)

/etc/systemd/system/safe-mode.service

[Unit]
Description=Safe Mode Alert

[Service]
Type=oneshot
# SE 的自救动作：点亮红灯、发短信报警、或者回滚分区
ExecStart=/bin/echo "CRITICAL: 检测到重启风暴，已进入安全模式！"

---

3. 运行流程 (The Flow)

1. 启动 : unstable-app 启动 -> 崩溃。
2. 重试 1 : Systemd 重启它 -> 崩溃。
3. 重试 2 : Systemd 重启它 -> 崩溃。
4. 触发阈值 : Systemd 发现 "10秒内崩了3次"。强制停止 unstable-app。
5. 故障转移 : Systemd 自动启动 safe-mode.service。

SE 经验总结:

永远不要只写 Restart=always 而不加 StartLimit。

这是"偶尔故障"和"设备变砖"之间的区别。