长时间运行后 polling 陷入死循环（httpx Pool timeout / Server disconnected）需要 kill 进程才能恢复

[lvheguo5-hub]

问题描述

CCBot v0.1.0（commit 865ab89）在长时间运行后会陷入"假死"状态——进程还活着但 Telegram polling 完全失能，新消息收不到，必须 kill 进程后由 launchd 重启才能恢复。重启后短期能正常工作，但很快又陷入同样状态。

现象

bot 进程不退出（launchctl list 状态 0），Telegram API 直接 curl getMe 也通，但 bot 内部的 polling/请求全部 timeout。stderr 里反复出现两类错误：

telegram.error.TimedOut: Pool timeout: All connections in the connection pool are occupied. 
Request was *not* sent to Telegram. Consider adjusting the connection pool size or the pool timeout.

httpcore.RemoteProtocolError: Server disconnected without sending a response.
telegram.error.NetworkError: httpx.RemoteProtocolError: Server disconnected without sending a response.

telegram.error.TimedOut: Timed out
ccbot.handlers.status_polling - DEBUG - Topic probe error for @2: Timed out
ccbot.handlers.status_polling - DEBUG - Topic probe error for @3: Timed out
...

Pool timeout: All connections in the connection pool are occupied 这条是关键——看起来 httpx 的连接池被占满后无法回收，后续所有请求都拿不到连接。

复现频率（实测数据）

我装了一个 launchd watchdog 每 5 分钟检测 stderr 静默 > 120s 自动 kickstart 重启。从昨天装好到现在的实际重启次数：

昨天（2026-04-25）: 9 次
今天（2026-04-26）截止 13:30: 62 次

今天部分时间分布（每 5 分钟稳定救一次 = 救完立刻又陷入死循环）：

09:17 09:23 09:28 09:33 09:38 09:43 09:48 09:53
10:03 10:08 10:13 10:18 10:23 10:28 10:33 10:38 10:43 10:48 10:53 10:58
11:03 11:08 11:18 11:23 11:28 11:34 11:44 11:49 11:54 11:59
12:04 12:09 12:14 12:19 12:24 12:29 12:34 12:39 12:44 12:49 12:54 12:59
13:04 13:09 13:14 13:19 13:25 13:30

也观察到偶尔有几小时健康期（昨晚 03:21 → 07:51 之间没死过），但触发后会进入"5 分钟连续死"的循环。

已尝试

• MONITOR_POLL_INTERVAL=10（默认 2）→ 频率没明显改善
• 回滚 MONITOR_POLL_INTERVAL=2 → 一样
• 重启 bot 进程 → 短期正常，几分钟后又复发

POLL interval 跟假死频率关系不大。

环境

• macOS 26.4.1
• Python 3.13.7
• CCBot v0.1.0（uv tool install，commit 865ab89）
• python-telegram-bot 走 httpx 后端
• 网络环境：中国大陆，通过 Clash Verge TUN 模式路由出境（其他通过 httpx 的服务都正常，只有 ccbot 的 polling 持续 timeout）

期望

希望作者能看一下 httpx 连接池管理逻辑：

1. 是否在某些异常路径下没有正确释放连接（比如 Server disconnected 错误后 connection 没回到池）
2. 是否可以在检测到 Pool timeout 之类 fatal 状态时主动重建 client
3. 或暴露 HTTPX_POOL_LIMIT 之类配置项让用户调

临时缓解方案（分享给可能遇到相同问题的用户）

我自己写了个 launchd watchdog 每 5 分钟跑一次自动重启，bot 总体可用：

#!/bin/bash
# ~/.ccbot/watchdog.sh - 假死自检 + 自动重启
LOG="$HOME/.ccbot/stderr.log"
LABEL="com.dazhi.ccbot"

# bot 进程不在 → launchd 自己处理
launchctl list 2>/dev/null | grep -q "$LABEL" || exit 0

# stderr.log 静默 > 120s = 假死
mtime=$(stat -f %m "$LOG" 2>/dev/null || stat -c %Y "$LOG")
age=$(( $(date +%s) - mtime ))
[ "$age" -gt 120 ] && launchctl kickstart -k "gui/$(id -u)/$LABEL" && exit 0

# 近 100 行错误占比 > 50% = 假死
errors=$(tail -100 "$LOG" 2>/dev/null | grep -cE 'Timed out|RemoteProtocolError|Server disconnected|ConnectError|ReadError')
[ "$errors" -ge 50 ] && launchctl kickstart -k "gui/$(id -u)/$LABEL"

但这只是临时止血，真正的连接池泄漏问题还得从 ccbot 内部修。

感谢作者！工具整体设计很好（tmux 桥接 + 跟桌面 session 互通），就是这个连接池问题让长时间运行不太稳定。希望能修。

[lvheguo5-hub]

更新（2026-04-26 晚）：之前的频率数据有水分，需要修正

抱歉，之前贴的"62 次/天 / 5 分钟一次假死"主要是我自己的 watchdog 误判，不是 CCBot 真的死那么多。要修正一下数据，免得误导作者优先级判断。

真正的根因（自己 watchdog 错判）

我之前的 watchdog.sh 有这段判断：

# stderr.log mtime > 120s 就判定假死，触发 kickstart
mtime=$(stat -f %m "$LOG")
age=$(( $(date +%s) - mtime ))
if [ "$age" -gt 120 ]; then
  launchctl kickstart -k "gui/$(id -u)/$LABEL"
fi

问题：CCBot idle 时本来就不写 stderr.log（没消息就没日志），watchdog 看到 mtime 老就误判"假死"。kickstart 重启后 stderr 被启动日志填上 → 几分钟后又老 → 又被误判 → 自激循环。

也就是说：之前每 5 分钟一次的 kickstart 大半是 watchdog 误杀健康 bot，不是 bot 真死。

修正后的真实数据

把 watchdog 改成更精准的判定（只对 launchd PID 不存在 / stderr 错误风暴 ≥50% / Telegram getMe 连续 3 次失败 才 kickstart）后：

指标	旧 watchdog（误判期）	新 watchdog（精准期）
时间窗	18:47 之前	18:47 - 现在（100+ 分钟）
kickstart 次数	125 次	0 次
stderr Pool timeout 数	83+ 条	0 条
实际 bot uptime	平均 ~5 分钟	100 分钟+ 持续运行

但 Pool timeout / Server disconnected 是真的（83 条）

这部分不是误判——CCBot 跑一段时间确实会出现：

telegram.error.TimedOut: Pool timeout: All connections in the connection pool are occupied.
httpcore.RemoteProtocolError: Server disconnected without sending a response.

可能跟 PTB 默认 pool_timeout=1.0 太短有关（高负载下连接池等连接的容忍度太低），但频率没我之前以为的那么高——可能几小时一次而不是几分钟一次。

建议（修正后）

• 优先级从 critical 降到 medium——CCBot 总体可用，不是"5 分钟必死"
• 但仍建议把 PTB HTTPXRequest 的 pool_timeout / keepalive_expiry 暴露成配置项（或默认调高），让长时间运行更稳
• 给可能误判 bot "假死"的用户建议：watchdog/heartbeat 不要用 stderr 静默作为信号，要用 Telegram /getMe API 探针

抱歉之前数据虚高带来的困扰。CCBot 整体设计很好（tmux 桥接 + 跟桌面 session 互通），只是连接池细节值得优化。