服务看门狗（Services Watchdog）

问题

从父 Shell（或作为 agent runtime 的子进程）启动的长期运行 Node 服务，在父进程退出时会随之终止。运行时重启行为尤为激进——往往将自身派生的所有子进程一并终止，造成“附带损害”。手动使用 nohup/setsid 可在 SSH 断连后维持进程存活，但无法抵御系统重启。

架构

my-watchdog.timer          (systemd --user；OnUnitActiveSec=2min)
    ↓
my-watchdog.service        (Type=oneshot；KillMode=process)
    ↓
services-watchdog.sh
    ↓
对每个服务：检查 → 若已停止 → systemd-run --user --scope → exec node

有两个不易察觉的关键设计，使该方案真正可靠：

1. KillMode=process + systemd-run --user --scope —— 若无此组合，systemd 在 Type=oneshot 服务退出后，会立即杀死其所有子进程。该组合将每次重启的服务置于独立的瞬态 scope 中，使其脱离看门狗自身的 cgroup。
2. .env 文件在新 scope 内加载。 看门狗将启动命令封装为：bash -c 'cd && set -a && . ./.env; set +a && exec node '。此举可自动传播全部环境变量，无需看门狗预知服务所需的具体变量（如 TELEGRAM_BOT_TOKEN、OPENAI_API_KEY 等）。

文件

• scripts/services-watchdog.sh — 主脚本。请按需定制各服务对应的 check_* / restart_* 逻辑块。
• scripts/sahi-watchdog.service — systemd 用户级 unit 模板。
• scripts/sahi-watchdog.timer — 每 2 分钟触发一次。

采用时，请将 unit 文件重命名为符合您项目前缀的名称（例如 mybot-watchdog.*）。

安装

WORKSPACE="$HOME/.openclaw/workspace"     # 或您的项目所在路径
mkdir -p "$WORKSPACE/scripts" "$WORKSPACE/logs" ~/.config/systemd/user

cp scripts/services-watchdog.sh   "$WORKSPACE/scripts/"
cp scripts/sahi-watchdog.service  ~/.config/systemd/user/
cp scripts/sahi-watchdog.timer    ~/.config/systemd/user/
chmod +x "$WORKSPACE/scripts/services-watchdog.sh"

systemctl --user daemon-reload
systemctl --user enable --now sahi-watchdog.timer
loginctl enable-linger "$USER"   # 确保用户未登录时 timer 仍持续运行

验证

# 最近一次执行后的状态：
cat ~/.openclaw/workspace/memory/watchdog-state.json
# 最近的恢复/失败记录：
tail ~/.openclaw/workspace/logs/watchdog.log
# 当前定时器调度情况：
systemctl --user list-timers sahi-watchdog.timer --no-pager

端到端测试（将 4321 替换为您服务实际监听的端口）：

PID=$(ss -tlnp 2>/dev/null | awk '/:4321 /{print $NF}' | grep -oP 'pid=[0-9]+' | head -1)
kill "$PID"
systemctl --user start sahi-watchdog.service   # 无需等待 2 分钟
ss -tln | grep 4321                            # 应再次显示监听中

（切勿使用 pkill -f "myservice/server.js" 终止测试目标——您当前的 exec shell 很可能匹配相同正则表达式，从而被误发 SIGTERM。）

适配新服务

在 services-watchdog.sh 中，需新增三项内容，并将服务名追加至 services=() 数组：

check_myservice() {
  pgrep -f "" >/dev/null 2>&1
}

restart_myservice() {
  cd "$WORKSPACE/projects/myservice" || return 1
  systemd-run --user --scope --quiet --unit="myservice-$(date +%s%N)" 
    --setenv=PATH="$PATH" --setenv=HOME="$HOME" 
    bash -c 'cd '"$WORKSPACE"'/projects/myservice && set -a && [ -f .env ] && . ./.env; set +a && exec nohup node src/index.js >> logs/svc.log 2>&1 < /dev/null' &
  disown 2>/dev/null || true
  sleep 3
  check_myservice
}

labels_myservice="My Service"

注意事项（血泪教训）

• 不要对 systemd service 使用 Type=simple —— 这会导致看门狗自身在完成任务后仍长期驻留内存，并在每 2 分钟重复触发。
• systemd-run --user --scope 内部的 PATH 极其精简。 若子进程依赖 ~/.npm-global/bin 等路径，请始终显式传入 --setenv=PATH="$PATH"；或直接使用绝对路径调用二进制文件。
• pgrep -f 可能误匹配看门狗自身的 shell 进程。 定义 check_* 时，请使用具备唯一性的标记（如文件路径），例如 pgrep -f "myservice/src/index"，而非宽泛的 pgrep -f "node src/index.js"（后者易与其他项目冲突）。
• Type=oneshot 配合默认的 KillMode=control-group 会杀死您刚刚启动的子进程。务必设置 KillMode=process，并始终通过 systemd-run --user --scope 启动，确保新进程脱离看门狗的 cgroup。

参见

• taskflow 或 cron 技能适用于一次性定时任务。本看门狗专为“常驻型”服务设计，不适用于周期性作业。