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

ini 复制代码
[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

ini 复制代码
[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

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

相关推荐
tao3556673 分钟前
VS Code登录codex,报错(os error 10013)
java·服务器·前端
橘颂TA3 分钟前
【剑斩OFFER】算法的暴力美学——leetCode 946 题:验证栈序列
c++·算法·leetcode·职场和发展·结构与算法
Hey小孩5 分钟前
[个人总结] LDD3:3.字符驱动 - scull(4)
linux·驱动开发
闻缺陷则喜何志丹6 分钟前
【状态机动态规划】3686. 稳定子序列的数量|1969
c++·算法·动态规划·力扣·状态机动态规划
陈让然6 分钟前
VS Code新版本无法连接WSL ubuntu18.04
linux·运维·ubuntu
liulilittle8 分钟前
OPENPPP2 网络驱动模式
开发语言·网络·c++·网络协议·信息与通信·通信
oMcLin9 分钟前
如何在Oracle Linux 8.4上通过配置Oracle RAC集群,确保企业级数据库的高可用性与负载均衡?
linux·数据库·oracle
小杰帅气10 分钟前
神秘的环境变量和进程地址空间
linux·运维·服务器
Vect__11 分钟前
基于CSAPP对链接和库的理解
linux
mjhcsp11 分钟前
C++ AC 自动机:原理、实现与应用全解析
java·开发语言·c++·ac 自动机