From 7ea91baee6011e538fc031e5d88fb4e0f39e5d6a Mon Sep 17 00:00:00 2001 From: yibo Date: Fri, 7 Aug 2026 14:25:30 +0800 Subject: [PATCH] ops(wechat): 修复微信回复 watcher 误重启 + 隧道自愈并入看门狗 --- docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md | 110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------- wechat_plain/scripts/auto-reply/wechat_reply_watcher.py | 43 +++++++++++++++++++++++++++++++------------ 3 files changed, 198 insertions(+), 22 deletions(-) create mode 100644 docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md diff --git a/docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md b/docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md new file mode 100644 index 0000000..80656f3 --- /dev/null +++ b/docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md @@ -0,0 +1,110 @@ +# task.hexdo.com 隧道重新分配 + 微信回复 watcher 误重启修复 + +> 时间：2026-08-07 +> 触发：用户反馈「pixel 的反向代理不能用了 task.hexdo.com」 + +--- + +## 一、task.hexdo.com 反代排查与重新分配 + +### 起因排查 + +`task.hexdo.com` 最初被以为是 Pixel 手机 `wechat-viewer` 的反代域名，但实际排查发现：这个域名自 **2026-06-15 创建起就一直 CNAME 到 Mac 上 `agent-bridge` 仓库的 `claude-yi` cloudflared 隧道**（源站是 pm2 管理的 bridge 进程，health port 10003），跟手机完全无关——用 Cloudflare API 直接查 DNS 记录的 `created_on` 字段坐实了这一点，不是「本来指手机、后来被改掉」，而是从来没指过手机。 + +Mac 侧当时的故障是两个独立组件都被手动停掉、没人重新拉起： +- pm2 里 `claude-yi` 这个 entry 整个不存在（不是 stopped，是没了） +- launchd job `com.hexdo.cloudflared-claude-yi` 完全没有 bootstrap（`launchctl list` 查不到） + +两边日志都在 2026-07-30 17:18 前后干净 `SIGTERM` 退出，时间戳吻合，判断是一次性手动停止后忘记恢复。修复： +```bash +cd ~/Documents/LemonAI/agent-bridge/agents/claude-yi && ./start.sh +launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.hexdo.cloudflared-claude-yi.plist +``` + +### 架构决策：域名重新分配 + +确认现状后，用户明确决定：`task.hexdo.com` 改专属 Pixel 手机的 `wechat-viewer`，Mac 的 `agent-bridge` 换一个新域名 `bridge.hexdo.com`。用 Cloudflare API（凭证从 Mac `~/.cloudflared/cert.pem` 里解出 `zoneID`/`accountID`/`apiToken`，因为 `cloudflared tunnel route dns --overwrite-dns` 这个版本实测不生效）直接 PATCH DNS 记录完成切换： + +1. Mac 上 `cloudflared tunnel create pixel-wechat-viewer` 生成手机要用的新隧道凭证（`~/.cloudflared/704efd12-a194-45dc-8333-4d6952eeb66f.json`） +2. `cloudflared tunnel route dns claude-yi bridge.hexdo.com` 给 Mac 隧道挂新域名 +3. Cloudflare API PATCH 把 `task.hexdo.com` 的 CNAME 记录改指向新隧道 `704efd12-....cfargotunnel.com` +4. Mac `~/.cloudflared/config.yml` 的 ingress hostname 从 `task.hexdo.com` 改成 `bridge.hexdo.com`，`launchctl kickstart -k` 重连 +5. 新隧道凭证 + `config.yml`（ingress `task.hexdo.com → http://127.0.0.1:5001`）通过 `adb push /sdcard/` 中转（不能直接 push 进 Termux 私有目录，会 Permission denied）+ `su -c cp/chown` 落到手机 `~/.cloudflared/` + +### 踩的坑：进程属主必须是 termux 应用自己的 uid，不能是 root + +手动验证时图省事用 `su -c 'setsid nohup cloudflared ...'` 起了一次隧道——这样起的进程属主是 **root**。但看门狗脚本、cron 调度器实际都以 Termux 应用自己的 uid（当时是 `u0_a329`，数字 uid `10329`）跑，**Android 有进程可见性隔离，非 root 的 `pgrep`/`ps` 看不到 root 拥有的进程**，会导致看门狗永远以为隧道没起、每次都想再起一个，还会因为想写日志到 root 占用的旧文件而权限不够。 + +正确做法：`su -G 3003 -c '...'` 以 termux 自己的身份起（`-G 3003` 是保住 `inet` 组权限，否则 DNS 会断，这条是这台设备的老坑，见 `~/.claude/projects/.../memory/magisk-su-android-inet-group.md`）。cloudflared 二进制 + `~/.cloudflared/` 下的凭证/配置全是 termux 应用自己拥有，**这个隧道进程完全不需要 root**。 + +### 隧道自愈并入已有看门狗（没有另建新 skill） + +Pixel 上本来就有一个每 10 分钟跑一次的 cron job「WeChat Viewer 看门狗」（`~/.hermes/scripts/wechat-viewer-watchdog.sh`，`no_agent: true`，`deliver: origin`）。给它新增第 7 节： +1. `pgrep` 查 `pixel-wechat-viewer` 隧道进程在不在，不在就起 +2. 进程在不代表隧道通（连接可能卡死/边缘握手失败），实测 `curl https://task.hexdo.com/api/doctor` 才算数 +3. 不通就重启一次隧道进程，重启完还不通就 `echo` 一行诊断信息，不再无限重试 + +**为什么 echo 一行就等于「失联通知」**：Hermes cron 的 `no_agent=true` job 由调度器直接跑 `script`，**stdout 原样投递回创建这个 job 时所在的会话**（`deliver: origin`，源码 `hermes-agent/tools/cronjob_tools.py` 里 `no_agent`/`deliver` 参数的注释写明 "the script IS the job and its stdout is delivered verbatim"）；stdout 为空则静默不投递（这条 job 已经稳定跑了近 6000 次没有噪音骚扰过，验证过这个假设成立）。所以不需要另外写 `am broadcast` 发微信通知——脚本里但凡有异常就 `echo`，正常就不 `echo`，天然就是失联通知。 + +### 最终状态 + +- `task.hexdo.com` → Pixel 手机 `pixel-wechat-viewer` 隧道 → `127.0.0.1:5001`（wechat-viewer），验证 `curl https://task.hexdo.com/api/doctor` → 200 +- `bridge.hexdo.com` → Mac `claude-yi` 隧道 → `127.0.0.1:10003`（agent-bridge），验证 `curl https://bridge.hexdo.com/health` → 200 +- 手机侧持久化：`~/.termux/boot/start-wechat-viewer`（Termux:Boot 脚本）末尾加了隧道启动命令，重启设备后自动拉起；顺手把该脚本里写死多年的 `fuser -k 5000/tcp` 改成了实际监听端口 `5001`（app.py 早就改用 5001，旧的 kill 命令一直在误杀空气） + +--- + +## 二、微信自动回复 watcher 误重启修复 + +### 症状 + +同一个看门狗脚本第 5 节（微信自动回复 watcher 单例保护）里，`watchdog.log` 天天刷屏「微信 Watcher 存活数=0(期望 1)，重置中... 重置后存活数异常: 0」，几乎每个 cron 周期（10 分钟）都触发一次。 + +### 根因：探测本身不可靠，不是进程真的挂了 + +第 5 节原本靠 `su -c 'ps -A' 2>/dev/null | grep -c '[w]echat_reply_watcher'` 判活。现场用同一个 adb 会话连续两条命令直接实锤：`ps -A | grep -c` 报 0，紧接着（不到 1 秒）`ps -A -o PID,ARGS | grep` 却找到了同一个 PID——**探测本身在系统负载下会偶发返回空/截断，哪怕进程明明活着**。这跟 `wechat-reply-watcher-process-leak.md` 记录的 2026-07-25 877 进程雪球事故是同一个底层不可靠因子（那次是"探测漏检 → 没先 pkill 就叠加新实例 → 雪球"；这次探测漏检的后果没那么严重，因为 7-25 之后已经加了"重置时先 pkill 清场"的幂等防线，不会再雪球，但会白白重启健康进程，在 1-2 秒空窗期有漏消息风险，且日志噪音很大）。 + +### 修复 + +`wechat_reply_watcher.py`：daemon 启动时把自己 PID 写进 `~/.hermes/wechat_reply/watcher.pid`（`_write_pidfile()`，正常/异常退出时 best-effort 清理，虽然 `pkill` 走 SIGTERM 默认终止不会触发 Python 的 `finally`，所以真正兜底还是靠下面的 `/proc` 存在性检查）。 + +`wechat-viewer-watchdog.sh` 第 5 节判活逻辑换成： +```bash +if [ -f "$WATCHER_PID_FILE" ]; then + WPID=$(cat "$WATCHER_PID_FILE" 2>/dev/null) + if [ -n "$WPID" ] && su -c "test -r /proc/$WPID/cmdline && grep -q wechat_reply_watcher /proc/$WPID/cmdline" 2>/dev/null; then + WATCHER_ALIVE=1 + fi +fi +``` +单次读 `/proc//cmdline` 比解析整个 `ps -A` 输出更轻量也更可靠，同时用 cmdline 内容校验防止 PID 复用误判成"还活着"。**"判活为假才重置"这个新逻辑没有削弱 7-25 加的防线**——一旦触发重置，仍然是先 `pkill -f wechat_reply_watcher.py` 清场再起新实例，不单纯信 pidfile 干净。 + +### 顺手修的独立小 bug：日志重复写 + +`log()` 函数同时 `print()`（会被 daemon 启动命令 `>> watcher.log 2>&1` 的 stdout 重定向捕获一次）又显式 `open(LOG_FILE,'a').write()` 同一个文件——每行日志被写两遍。历史 `watcher.log` 里所有行成对重复就是这个原因，纯噪音不影响功能，删掉了显式文件写那段，只留 `print()`。 + +### 验证 + +手动清场（`pkill`）后跑一次看门狗，触发重置成功、pid 记入 pidfile；**立即**再跑第二次看门狗——即使当次 `ps -A | grep -c` 依然复现性地报 0（证明探测本身的不可靠是持续存在的环境事实，不是偶发），pidfile+cmdline 检测正确判定「还活着」，没有触发不必要的重置。`watcher.log` 新写入的行确认不再重复。 + +### 遗留、未处理的问题 + +诊断过程中在手动跑整个看门狗脚本时看到「Gateway 不在线，重启中... `/tmp/hermes-gateway.log: Permission denied`」——这是我手动用 `su -G 3003 -c` 从 adb 触发时的执行环境差异（缺少 Termux 自身的 `LD_PRELOAD`/路径重写机制），不代表真实 cron 执行环境下也会失败，没有进一步处理，如果之后在真实 `watchdog.log` 里持续看到这条才需要认真排查。 + +--- + +## 涉及文件 + +- `~/.cloudflared/config.yml`（Mac，ingress 改 `bridge.hexdo.com`） +- `~/.cloudflared/pixel-config.yml` → 手机 `~/.cloudflared/config.yml`（新建，ingress `task.hexdo.com`） +- `~/.termux/boot/start-wechat-viewer`（手机，Termux:Boot 脚本，加隧道启动 + 修端口号） +- `~/.hermes/scripts/wechat-viewer-watchdog.sh` = 本仓库 `wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh`（新增第 7 节隧道自愈 + 第 5 节判活改用 pidfile） +- `~/.hermes/wechat_reply/wechat_reply_watcher.py` = 本仓库 `wechat_plain/scripts/auto-reply/wechat_reply_watcher.py`（新增 pidfile 写入 + 修日志重复写） + +设备上对应文件均留有 `.bak-20260807*` 备份。 + +## 相关记忆 + +- `task-hexdo-reverse-proxy-outage.md`（pixelphone 项目 memory） +- `task-hexdo-tunnel-clash-direct.md`（agent-bridge 项目 memory，Mac 侧 Clash TUN 劫持等历史故障模式，域名已改成 `bridge.hexdo.com`） +- `wechat-reply-watcher-process-leak.md`（pixelphone 项目 memory，2026-07-25 877 进程雪球事故 + 本次后续修复） diff --git a/wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh b/wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh index b81d6ad..8e79d10 100755 --- a/wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh +++ b/wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh @@ -55,24 +55,37 @@ python3 "$APP_DIR/reap_orphan_reports.py" >> "$LOG" 2>&1 # ── 5. 微信自动回复 Watcher ──────────────────────── # 监听微信 DB 变化，写入 incoming.jsonl 队列 -# 单例保护：每次都先 pkill 清场再起一个，不能只信一次 ps|grep 的探测结果—— -# 探测在系统过载时会漏检/超时返回空，若不清场会在卡死的旧实例上再叠一个， -# 雪球式堆积出几百个进程拖垮整机（2026-07-25 事故：堆到 877 个吃满内存+swap）。 +# 单例保护：判活用 pidfile+kill -0（不是 `ps -A | grep`）——2026-08-07 实测 +# `su -c 'ps -A'` 经 adb/su 转一手会偶发返回空/截断，哪怕进程明明还活着， +# 导致看门狗把健康进程当挂了、每个 cron 周期都重置一次（"重置后存活数异常" +# 的假象），既白白重启浪费资源，也在重启的 1-2 秒空窗里可能漏消息。 +# 重置动作本身仍先 pkill 清场再起（不只信 pidfile 干净），避免卡死的旧实例 +# 没被 pidfile 反映出来、跟新实例叠加——2026-07-25 事故就是堆到 877 个进程 +# 吃满内存+swap，这条防线不能丢。 REPLY_DIR=$HOME_DIR/.hermes/wechat_reply -WATCHER_COUNT=$(su -c 'ps -A' 2>/dev/null | grep -c '[w]echat_reply_watcher') +WATCHER_PID_FILE=$REPLY_DIR/watcher.pid +WATCHER_ALIVE=0 -if [ "$WATCHER_COUNT" -ne 1 ]; then - echo "[$(date)] 微信 Watcher 存活数=$WATCHER_COUNT(期望 1)，重置中..." | tee -a "$LOG" +if [ -f "$WATCHER_PID_FILE" ]; then + WPID=$(cat "$WATCHER_PID_FILE" 2>/dev/null) + if [ -n "$WPID" ] && su -c "test -r /proc/$WPID/cmdline && grep -q wechat_reply_watcher /proc/$WPID/cmdline" 2>/dev/null; then + WATCHER_ALIVE=1 + fi +fi + +if [ "$WATCHER_ALIVE" -ne 1 ]; then + echo "[$(date)] 微信 Watcher 未存活(pidfile 检测)，重置中..." | tee -a "$LOG" su -c "pkill -f wechat_reply_watcher.py" 2>/dev/null sleep 1 + rm -f "$WATCHER_PID_FILE" su -c "/data/data/com.termux/files/usr/bin/python3 $REPLY_DIR/wechat_reply_watcher.py >> $REPLY_DIR/watcher.log 2>&1 &" sleep 2 - WATCHER_COUNT2=$(su -c 'ps -A' 2>/dev/null | grep -c '[w]echat_reply_watcher') - if [ "$WATCHER_COUNT2" -eq 1 ]; then - echo "[$(date)] 微信 Watcher 重置成功" | tee -a "$LOG" + WPID2=$(cat "$WATCHER_PID_FILE" 2>/dev/null) + if [ -n "$WPID2" ] && su -c "test -r /proc/$WPID2/cmdline" 2>/dev/null; then + echo "[$(date)] 微信 Watcher 重置成功(pid=$WPID2)" | tee -a "$LOG" else - echo "[$(date)] 微信 Watcher 重置后存活数异常: $WATCHER_COUNT2" | tee -a "$LOG" + echo "[$(date)] 微信 Watcher 重置后仍未存活" | tee -a "$LOG" fi fi @@ -89,3 +102,37 @@ if [ -f "$ORCH_LOCK" ]; then fi su -c "/data/data/com.termux/files/usr/bin/python3 $REPLY_DIR/wechat_reply_orchestrator.py --drain >> $REPLY_DIR/orchestrator.log 2>&1" + +# ── 7. task.hexdo.com 隧道 ────────────────────────── +# Cloudflare 隧道 pixel-wechat-viewer(→ 127.0.0.1:5001)，用 termux 用户身份跑， +# 不需要 su。2026-08-07 之前这里完全没人巡检——本地 Flask 一直活着，但对外的 +# task.hexdo.com 挂了一周多都没被发现，靠这次手动排查才补上。 +# 详见 pixelphone 仓库 memory task-hexdo-reverse-proxy-outage.md。 + +CF_DIR=$HOME_DIR/.cloudflared +TUNNEL_ALIVE=$(pgrep -f "cloudflared tunnel --config.*pixel-wechat-viewer" 2>/dev/null | wc -l) + +if [ "$TUNNEL_ALIVE" -eq 0 ]; then + echo "[$(date)] cloudflared 隧道进程不在，启动中..." | tee -a "$LOG" + nohup cloudflared tunnel --config "$CF_DIR/config.yml" run pixel-wechat-viewer \ + > "$CF_DIR/tunnel.log" 2>&1 & + sleep 5 +fi + +# 进程在不代表隧道通（连接可能卡死/边缘握手失败），实测公网端点才算数 +PUBLIC_CODE=$(curl -sS -m 8 -o /dev/null -w '%{http_code}' https://task.hexdo.com/api/doctor 2>/dev/null) + +if [ "$PUBLIC_CODE" != "200" ]; then + echo "[$(date)] task.hexdo.com 探测异常(http_code=$PUBLIC_CODE)，重启隧道..." | tee -a "$LOG" + pkill -f 'cloudflared tunnel --config.*pixel-wechat-viewer' 2>/dev/null + sleep 1 + nohup cloudflared tunnel --config "$CF_DIR/config.yml" run pixel-wechat-viewer \ + > "$CF_DIR/tunnel.log" 2>&1 & + sleep 8 + PUBLIC_CODE2=$(curl -sS -m 8 -o /dev/null -w '%{http_code}' https://task.hexdo.com/api/doctor 2>/dev/null) + if [ "$PUBLIC_CODE2" = "200" ]; then + echo "[$(date)] task.hexdo.com 隧道重启后恢复" | tee -a "$LOG" + else + echo "[$(date)] task.hexdo.com 隧道重启后仍异常(http_code=$PUBLIC_CODE2)，需要人工看一下 $CF_DIR/tunnel.log（Mac 上 bridge.hexdo.com 是另一条独立隧道，不受影响）" | tee -a "$LOG" + fi +fi diff --git a/wechat_plain/scripts/auto-reply/wechat_reply_watcher.py b/wechat_plain/scripts/auto-reply/wechat_reply_watcher.py index f430cb5..cd46800 100644 --- a/wechat_plain/scripts/auto-reply/wechat_reply_watcher.py +++ b/wechat_plain/scripts/auto-reply/wechat_reply_watcher.py @@ -44,6 +44,7 @@ STATE_FILE = f"{WORK_DIR}/state.json" CONFIG_FILE = f"{WORK_DIR}/config.json" QUEUE_FILE = f"{WORK_DIR}/incoming.jsonl" LOG_FILE = f"{WORK_DIR}/watcher.log" +PID_FILE = f"{WORK_DIR}/watcher.pid" IMEI = "1234567890ABCDEF" # inotify 常量 @@ -58,13 +59,11 @@ MTIME_POLL = 4.0 # inotify 不可用时的兜底轮询间隔 def log(msg): + # 只 print：daemon 模式下调用方(watchdog/cron)一律把 stdout+stderr 重定向到 + # LOG_FILE，这里再显式 open().write() 同一个文件会把每一行都写两遍 + # (2026-08 发现 watcher.log 里所有行都成对重复，根因就是这个)。 line = f"{time.strftime('%Y-%m-%d %H:%M:%S')} {msg}" print(line, flush=True) - try: - with open(LOG_FILE, "a") as f: - f.write(line + "\n") - except OSError: - pass def md5hex(s: str) -> str: @@ -359,18 +358,38 @@ def make_inotify(watch_dir): return libc, fd +def _write_pidfile(): + # 看门狗靠这个文件 + kill -0 判活，取代不可靠的 `ps -A | grep` + # (2026-08 实测 `su -c 'ps -A'` 经 adb/su 转一手偶发返回空/截断， + # 哪怕进程明明还活着，导致看门狗把健康进程当挂了反复重启)。 + try: + with open(PID_FILE, "w") as f: + f.write(str(os.getpid())) + chown_to_hermes(PID_FILE) + except OSError: + pass + + def daemon(): _, db, _ = account_paths() watch_dir = os.path.dirname(db) os.makedirs(WORK_DIR, exist_ok=True) chown_to_hermes(WORK_DIR) - libc, fd = make_inotify(watch_dir) - if fd is not None: - log(f"inotify 监听 {watch_dir}") - _watch_loop_inotify(fd) - else: - log(f"inotify 不可用,退回 mtime 轮询 {db}") - _watch_loop_mtime(db) + _write_pidfile() + try: + libc, fd = make_inotify(watch_dir) + if fd is not None: + log(f"inotify 监听 {watch_dir}") + _watch_loop_inotify(fd) + else: + log(f"inotify 不可用,退回 mtime 轮询 {db}") + _watch_loop_mtime(db) + finally: + try: + if os.path.exists(PID_FILE) and open(PID_FILE).read().strip() == str(os.getpid()): + os.remove(PID_FILE) + except OSError: + pass def _trigger_orchestrator(): -- libgit2 0.21.4