systemd本身不提供服务降级功能，降级必须由应用层实现；可通过BindsTo依赖联动、Type=notify+WatchdogSec健康反馈、ExecStartPre启动前探活三层路径协同实现。

Linux 中 systemd 服务本身不直接提供“服务降级”语义（如返回缓存、限流响应、关闭非核心模块等），它本质是进程生命周期管理器，负责启停、重启、依赖协调与状态追踪。所谓“故障自动降级运行”，实际是应用层逻辑 + systemd 配置协同实现的工程策略，而非 systemd 单独功能。

要让服务在故障时“降级运行”，关键在于：systemd 管住进程是否存活、何时重启、依赖是否就绪；而“降级”行为必须由服务自身或其启动环境主动触发。以下是可落地的三层实现路径：

一、用 BindsTo= + After= 实现依赖级降级联动

当关键依赖（如数据库、Redis）宕机时，避免服务盲目重连拖垮自身，而是主动进入轻量模式运行：

• 在 .service 文件中明确绑定依赖并控制启动顺序：

  [Unit]
  After=redis-server.service mysql.service
  BindsTo=redis-server.service mysql.service
  # 注意：BindsTo 要求依赖必须处于 active 状态，一旦 redis 崩溃，本服务自动 stop

• 服务代码中监听 systemd 通知或检查依赖可用性：

  • 启动时执行 curl -f http://localhost:6379/ping || echo "redis unavailable" >> /var/log/myapp/health.log
  • 若检测失败，跳过初始化 Redis 客户端，改用内存队列或本地文件暂存数据，对外返回 503 Service Degraded

✅ 效果：依赖消失 → systemd 自动停止服务 → 你可在 ExecStopPost= 中触发一个脚本，启动“降级版守护进程”（如 myapp-degraded --mode=cache-only）

二、用 Type=notify + WatchdogSec= 驱动健康态切换

让服务能主动上报自身能力等级，systemd 根据状态决定是否重启或容忍当前模式：

• 配置服务支持 notify 和看门狗：

  

  Browser Setup (No-Root Linux)

  在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

  下载

  [Service]
  Type=notify
  WatchdogSec=30
  Restart=on-watchdog
  ExecStart=/usr/bin/myapp --health-mode=auto

• 应用内逻辑：

  • 正常时每 20 秒调用 systemd-notify --watchdog=1
  • 检测到 DB 连接超时后，自动切换为只读缓存模式，并继续发 WATCHDOG=1
  • 若连续 3 次无法完成核心写操作，主动调用 systemd-notify "STATUS=Degraded: using local cache only" 并维持进程存活

✅ 效果：systemd 不杀进程，但日志和 systemctl status 明确显示降级状态；监控系统可基于 STATUS= 字段告警或自动扩容

三、用 ExecStartPre= + 外部探活脚本实现启动前动态降级

在每次重启前，根据环境条件决定启动完整版还是降级版：

[Service]
ExecStartPre=/usr/local/bin/check-and-choose-bin.sh
ExecStart=/usr/bin/myapp-prod
ExecStart=/usr/bin/myapp-degraded
Restart=on-failure
RestartSec=10

其中 /usr/local/bin/check-and-choose-bin.sh 内容示例：

#!/bin/sh
if ! timeout 3 curl -sf http://localhost:3306; then
  ln -sf /usr/bin/myapp-degraded /usr/bin/myapp-current
  logger "DB down → switching to degraded mode"
else
  ln -sf /usr/bin/myapp-prod /usr/bin/myapp-current
fi

再让 ExecStart= 直接调用 /usr/bin/myapp-current。

✅ 效果：每次崩溃重启前都重新评估环境，自动选择运行形态，无需人工干预

补充：避免常见误区

• ❌ 不要用 Restart=always 配合“死循环重试 DB 连接”——这会掩盖问题，且可能打满连接池
• ❌ 不要依赖 ExecStartPost= 做运行中降级——它只在启动成功后执行一次，无法响应运行时故障
• ✅ 推荐组合：BindsTo= 控制强依赖生命周期 + WatchdogSec+notify 实现运行时健康反馈 + 应用内 try/catch + fallback logic 承担降级动作

本质上，systemd 是“守门人”，不是“决策者”。真正的降级逻辑必须下沉到应用代码或启动封装脚本里，systemd 只负责确保这个逻辑被稳定、可观测、可中断地执行。