定时任务全瘫12小时零告警：一次systemd-run派发翻车与fail-closed排坑实录

摘要9 月 4 日早上我发现自己机器上 20 来个 AI Agent 定时任务从凌晨起一条都没跑累计 188 次失败但没有任何告警。根因不是脚本 bug也不是网络——是 Agent 框架自动更新后任务派发方式从直接执行改成了systemd-run --user --scope而我的网关是以系统级服务跑的用户级 systemd 总线根本够不着。本文完整复盘这次事故的排查链条、根因分析和修复方案适合所有自托管 Agent / 自动化任务重度用户。1. 背景一套跑了两个月的定时任务体系我的机器上有一套 Hermes Agent 定时任务体系跑了两个月覆盖行情监控、复盘、发文、数据同步20 多个 job最密的 5 分钟一次。这套东西的可靠性我是有信心的。之前踩过 cron 字段格式、脚本路径拼接、模型主备切换的坑都有对应的看门狗兜着独立看门狗系统 crontab 每 5 分钟跑一个cron_dispatch_watchdog.py与 Agent 框架的 cron 物理隔离监控失败率、进程存活、工作时段静默日志兜底失败任务会在 gateway 日志留痕所以 9 月 4 日早上 9 点我打开监控面板看到的是一幅诡异的画面。2. 事故现场188 次失败零告警先看事实从凌晨 0 点起所有定时任务全部失败累计 188 次看门狗一条告警都没发任务面板上失败记录的时间戳是 9 月 3 日——滞后了一天188 次失败零告警这件事本身比事故更值得写。后面细说。3. 排查三个假线索和一个真根因3.1 第一反应cron 配置坏了jobs.json读了一遍schedule 表达式、script 路径、模型配置全对。手动跑一次任务——正常。手动跑正常、定时跑全挂这个组合基本排除了脚本本身的问题。问题在派发层。3.2 假线索二网关挂了psaux|grepgateway进程活着端口在听API 响应正常。排除。3.3 假线索三模型配额/网络任务失败信息里如果出现 API 报错第一个该查的就是模型和配额。但这次失败的任务连 LLM 请求都没发出去死在更早的阶段。3.4 真根因agent.log 里的关键字翻agent.log注意不是gateway.log满屏都是这一行dispatch failed: Failed to start transient service unit: ...systemd-run。这个词一出来方向就清楚了。4. 根因分析一次自动更新引发的三重连锁4.1 事故链条flowchartTDA[Agent框架自动更新至新版]--B[任务派发改为systemd-run--user--scope]B--C{网关能否访问用户级systemd总线}|C--|系统级服务|D[缺少XDG_RUNTIME_DIR环境变量]|D--E[找不到用户bus地址/run/user/1000/bus]E--F[所有任务派发失败]F--G[失败188次持续12小时]G--H[看门狗探针同样依赖该环境br/探针永败且告警判定失效]H--I[零告警]4.2 逐层拆解第一层新版改了派发方式。旧版直接 fork 执行任务进程新版统一走systemd-run --user --scope把任务放进用户级 systemd 的 transient scope 里管理——设计意图是好的任务进程能被 systemd 托管资源统计、cgroup 归组都更规范。这属于 fail-closed 设计派发环境不满足要求就拒绝执行而不是带着残缺状态硬跑。第二层我的网关是系统级服务。systemd 服务里没有XDG_RUNTIME_DIR这个环境变量。systemd-run --user要连用户实例的总线总线地址默认从XDG_RUNTIME_DIR推导/run/user/1000/bus。变量缺失 → 找不到总线 → 派发失败。第三层看门狗为什么也瞎了。这是整场事故里最讽刺的一环。看门狗的健康探针本身也要经过 gateway 的派发链路——派发层坏了探针永远失败而看门狗的告警逻辑里探针失败被归为已知错误类型没有触发连续失败超阈值的升级告警。兜底机制和主机制死在了同一条链上。4.3 为什么零告警拖了 12 小时三个因素叠加错误只写在agent.loggateway.log 干净得像什么都没发生任务面板的 output 时间戳滞后一天看面板以为一切正常看门狗探针失效见上任何一层独立工作我都能在 30 分钟内发现。三层同时瞎这就是共享故障域的教科书案例——所谓冗余如果冗余通道和主通道共享同一个底层依赖就不是冗余。5. 修复三探针定位 一个环境变量5.1 诊断三探针修复前先确认根因跑了三个探针# 探针1无 XDG 环境下启动 scope模拟故障态sudo-uhnzwxenv-isystemd-run--user--scopetrue# 结果失败报 Failed to connect to bus# 探针2带 XDG 环境下启动 scope验证假设sudo-uhnzwxenvXDG_RUNTIME_DIR/run/user/1000systemd-run--user--scopetrue# 结果成功# 探针3确认用户 bus 存在 linger 状态ls-l/run/user/1000/busloginctlshow-userhnzwx-pLinger# 结果bus 存在Lingeryes用户不登录时用户实例也保活探针 1 失败、探针 2 成功假设闭环。探针 3 确认总线和 linger 都在说明只要环境变量补上链路就是通的。5.2 修复操作给 gateway 的.env加一行XDG_RUNTIME_DIR/run/user/1000然后重启网关手动触发一个任务验证派发恢复。5.3 修复后自检清单检查项方法预期手动派发触发一个轻量任务正常执行无 dispatch failedsystemd scopesystemctl --user status scope任务进程在 scope 内看门狗探针跑一次探针脚本探针成功告警计数清零次日定时任务次日抽查执行记录时间戳为当日无滞后6. 踩坑记录这次事故教我的五件事auto-update 不是免费的。自动更新引入的不只是功能变化还有执行环境的隐式契约。新版要求 systemd 用户总线但没有任何升级前检查。重要的生产系统自动更新要么关掉要么更新后第一件事就是抽查核心链路。错误日志的分层要看全。这次错误只在agent.loggateway.log一片祥和。排障 SOP 里查日志必须明确到文件级并且记住一条经验法则派发类错误先查 agent 侧日志连接类错误先查 gateway 侧。任务面板的时间戳会骗人。output 日期滞后一天这种监控数据本身过期的问题比没有监控更危险——它给了你虚假的安心。看门狗必须和被监控对象物理隔离还要逻辑隔离。我的看门狗进程是独立的系统 crontab但探针逻辑走了 gateway 的派发链路。修复方向看门狗的健康检查改为直连任务产物文件时间戳、数据库写入记录绕开派发层。fail-closed 是双刃剑。新版宁可拒绝执行也不带病硬跑这个设计本身没错。但 fail-closed 必须搭配 fail-loud——拒绝执行时要让失败信号以独立通道传出来否则就是静默死亡。7. 总结这次事故从凌晨 0 点持续到我早上 9 点介入12 小时、188 次失败、零告警。根因归结为一句话自动更新改变了任务的执行环境契约而监控体系的三个故障检测层共享了同一条失效路径。修复只花了一个环境变量但暴露的架构问题值得长期记住冗余设计要审查的不是我有没有第二套机制而是第二套机制和第一套是否共享故障域。你有没有遇到过类似的静默故障——监控和主系统一起瞎掉的情况你的看门狗的健康检查走的是哪条链路如果那条链路挂了它自己知道吗欢迎在评论区聊聊我准备把这套看门狗自检的方案整理成下一篇。