ops(wechat): 修复微信回复 watcher 误重启 + 隧道自愈并入看门狗

task.hexdo.com 探测发现指向错了 Mac 的 agent-bridge，域名重新分配后（详见 docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md），把 task.hexdo.com 隧道健康检查/自愈加进看门狗第 7 节；顺带修复微信自动回复 watcher 的判活逻辑（`ps -A|grep` 在设备负载下不可靠导致健康进程被误判重启），改用 pidfile + /proc/cmdline 判活，并修掉 log() 把每行日志写两遍的小 bug。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

ops(wechat): 修复微信回复 watcher 误重启 + 隧道自愈并入看门狗
task.hexdo.com 探测发现指向错了 Mac 的 agent-bridge，域名重新分配后（详见 docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md），把 task.hexdo.com 隧道健康检查/自愈加进看门狗第 7 节；顺带修复微信自动回复 watcher 的判活逻辑（`ps -A|grep` 在设备负载下不可靠导致健康进程被误判重启），改用 pidfile + /proc/cmdline 判活，并修掉 log() 把每行日志写两遍的小 bug。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
yibo
1 parent ead036cf
Showing 3 changed files with 198 additions and 22 deletions
docs/2026-08-07-task-hexdo-tunnel-and-wechat-watcher.md
wechat_plain/scripts/auto-reply/wechat-viewer-watchdog.sh
wechat_plain/scripts/auto-reply/wechat_reply_watcher.py
+# 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 <termux_uid> -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/<pid>/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 <uid> -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 进程雪球事故 + 本次后续修复）
@@ -55,24 +55,37 @@ python3 &quot;$APP_DIR/reap_orphan_reports.py&quot; &gt;&gt; &quot;$LOG&quot; 2&gt;&amp;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 &quot;$ORCH_LOCK&quot; ]; 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
@@ -44,6 +44,7 @@ STATE_FILE = f&quot;{WORK_DIR}/state.json&quot;
 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():