梦行志OpenClaw Gateway 反复重启排障：auditd 定位 SIGTERM 发送者与 memory-pressure 自保护机制
从 7 次 SIGTERM 到 root cause 定位：systemd、hot-reload、memory-pressure 三者交织的完整复盘
事故现场：一个小时后回来的意外发现
2026 年 8 月 3 日中午，我离开电脑处理其他事情。一个小时后回来，发现 OpenClaw gateway 的日志里写满了 SIGTERM 信号——在 11:56 到 13:05 这短短约 1 小时内，gateway 经历了 7 次 stop/restart。
没有任何异常告警，没有人工干预，整个系统像被"看不见的手"反复重启。直觉告诉我：这不是巧合，是有规律的底层问题正在暴露。
关键问题是：谁在发 SIGTERM？
排障第一步：收集所有日志
面对这种"幽灵重启"，第一反应不是猜测，而是把所有能拿到的日志全部拉出来，对齐时间线。
11:56 的首次重启——memory-pressure 触发的"自保"
通过 journalctl 查看 systemd 日志，发现最早的一次重启发生在 11:56：
11:56:38 — Stopped openclaw-gateway.service
11:56:38 — Started openclaw-gateway.service这看起来只是一个普通的 stop 然后 start。但深入检查 gateway 自己的日志，发现了关键线索：
11:56:39 [diagnostics/memory] rss_growth=45.26% (>30%); initiating restart原来 OpenClaw gateway 内置了 内存诊断自保护机制：当 RSS 增长超过 30% 阈值时，自动触发 restart 来释放内存。11:56 这次重启的原因是 45.26% 的 RSS 增长，远超阈值。
“凶手"是系统自己的内存保护。
12:05 的配置热重载——agents.list 变更触发的连锁反应
接下来是 12:05 前后的事件，这是最复杂、也最耐人寻味的一条主线。
日志显示了一个精确的时间链：
12:04:06 — tool policy 应用（31/32 个工具被移除）
12:04:25 — tool policy 再次应用
12:05:03 — [reload] config change detected; evaluating reload (agents.list)
12:05:05 — received SIGTERM; restarting
12:05:10 — [reload] config hot reload applied (agents.list)
12:05:35 — restart drain 超时 30s，systemd 发送 SIGKILL
12:05:39 — 新 gateway 进程（node[214699]）启动关键发现：在 12:05:03，gateway 检测到 agents.list 配置发生了变更，触发了热重载流程。但仅仅 2 秒后（12:05:05），gateway 就收到了 SIGTERM。
更关键的证据是：在 12:05 这个时间点，存在一个配置备份文件：
~/.openclaw/openclaw.json.bak-gateway-deny-20260803 (Modify: 12:05)通过 diff 对比，发现当前配置对比备份文件，多个 agent 被追加了 "deny": ["gateway"] 规则。这说明有人在 12:05 精确修改了配置，添加了 gateway-deny 规则。
12:06~13:05 的 5 次 SIGTERM 尚未定位
剩下的 5 次 SIGTERM 事件，目前仍无法通过现有日志直接定位来源：
| 时间 | 事件类型 | 来源确认 |
|---|---|---|
| 12:06:44 | stop（新进程启动后 66s） | ❌ 未知 |
| 12:31:01 | stop（systemd 自动重启） | ❌ 未知 |
| 12:41:40 | restart | ❌ 未知 |
| 12:49:22 | stop（用户手动拉起） | ❌ 未知 |
| 13:05:11 | stop（systemd 自动重启） | ❌ 未知 |
这也是为什么后来决定部署 auditd 的直接原因——日志只能告诉你"收到了信号”，但从不告诉你"谁发的信号"。
部署 auditd：让 SIGTERM 发送者"显形"
OpenClaw gateway 的日志只能记录"收到 SIGTERM，正在重启/停止"——它不知道是谁发的信号。systemd 的 journal 也只记录进程的 start/stop 状态，不记录信号的发送者。
要解决这个问题，必须引入 Linux 审计系统 auditd。
安装与规则配置
# 安装 auditd
sudo apt-get install -y auditd && sudo systemctl enable --now auditd
# 监控 node 进程的执行（gateway 是 node 进程）
sudo auditctl -a always,exit -F path=/usr/bin/node -F perm=x -k openclaw_gateway_signal
# 监控 kill/tkill/tgkill 系统调用（64 位系统需要指定 arch）
sudo auditctl -a always,exit -F arch=b64 -S kill -S tkill -S tgkill -k openclaw_gateway_signal注意：在 64 位系统上，监控 kill 系列系统调用必须指定 -F arch=b64，否则会报 WARNING - 32/64 bit syscall mismatch。另外，某些版本的 auditctl 对 -F auid>=1000 的解析有兼容性问题，如果遇到 -F missing operation for auid 错误，可以先去掉 auid 过滤。
如何查看 auditd 捕获的日志
规则生效后，下一次 gateway 被 SIGTERM 时，可以通过以下命令查看发送者：
# 查看最近的事件
ausearch -k openclaw_gateway_signal --start recent
# 或查看原始日志
sudo ausearch -k openclaw_gateway_signal | aureport -f -i
检查 search-scout-yuntianyan：受害者还是加害者？
在排查过程中，一个名为 search-scout-yuntianyan 的 agent 引起了注意——它的 session 文件显示在 12:05 前后有活跃轨迹。
通过检查它的 trajectory 文件（840140ce-0120-4ffd-832d-b041c9e59c37.trajectory.jsonl），发现：
- 12:03:46 — session 还在正常运行，提交了新的 prompt
- 12:04:06 — 完成了一次模型推理，但出现
"terminalError": "non_deliverable_terminal_turn" - 12:05:05 — gateway 重启，session 被中断
关键发现：search-scout-yuntianyan 的 trajectory 中没有任何 exec 工具调用包含 openclaw gateway、systemctl 或 gateway stop 等命令。它没有发出过任何 gateway 控制指令。
结论：这个 agent 是受害者，不是加害者。 它只是恰好在那段时间活跃，被 gateway 重启中断了工作。
确认的两条主线与待办清单
已确认的触发机制
| 触发时间 | 触发源 | 直接原因 | 解决方向 |
|---|---|---|---|
| 11:56 | 内存诊断自保护 | RSS 增长 45.26%，超过 30% 阈值 | 调整阈值 or 排查内存泄漏 |
| 12:05 | agents.list 配置变更 | 配置热重载触发重启流程 | 追踪配置变更者，优化热重载流程 |
未确认的 SIGTERM（等待 auditd 捕获）
12:06/12:31/12:41/12:49/13:05 这 5 次 SIGTERM 的来源，仍需要 auditd 在下次事件发生时捕获。
根本原因是：
在全场景模式下加载了290个agetn导致内存飙升爆炸！
后续加固建议
- 调整 memory-pressure 阈值：如果 30% 过于敏感，可以适当放宽到 50%~60%，或增加冷却时间
- 配置变更审计：对于
agents.list等关键配置，建立谁在什么时间修改的审计日志 - auditd 持久化规则：将 auditd 规则写入
/etc/audit/rules.d/，确保重启后仍然生效 - gateway drain 超时优化：30 秒的 drain 超时偏短，可考虑增加或优化 task draining 逻辑
排障方法论总结
这次排障给我最大的启发是：系统日志的"盲区"远比想象中多。
journalctl只记录进程状态，不记录信号发送者- OpenClaw gateway 日志只记录信号接收，不记录来源
- 普通运维工具无法捕获"谁杀了谁"的跨进程信息
auditd 是补全这个盲区的关键工具——它不依赖任何应用层的日志，直接在内核层面捕获系统调用，记录发送者的 PID、UID、命令等信息。
写在最后
gateway 反复重启看似是"抽风"，但每次 SIGTERM 背后都有明确的触发机制。这次排障虽然找到了两条主线，但仍有 5 次 SIGTERM 的来源等待 auditd 的后续捕获。
如果你也在使用 OpenClaw 或类似的自托管 AI 网关，强烈建议：
- 提前部署 auditd，不要等到出了问题再装
- 关注 memory-pressure 阈值，结合你的实际负载调整
- 建立配置变更的审计链路，谁改了
agents.list要有据可查
排障不是终点，加固才是。下一次 gateway 重启，我们就能知道是谁在"按开关"了。
关联阅读
- [[2026-07-28-1530-openclaw-production-ops-full-review|OpenClaw 生产运维全面复盘]]
- [[2026-06-04-1959-systemd-service-path排查|systemd service 路径排查记录]]
- [[2026-07-27-1700-kb-writer-重复读取死循环事件|kb-writer 重复读取死循环事件排查]]