 cnbugs
|
47714c9622
|
fix(socks5): stop_instance 置 enabled=False, 防 sync loop 自动重启用户手动停止的实例
回归 (eba7ae8 引入):
sync loop 周期调 sync_instances, 它只看 DB 里 enabled=True 的实例。
但 stop_instance 只停进程 + 设 running=False, 不改 enabled。
结果: 用户手动停止实例后, 30 秒内 sync loop 会把它当'死掉的实例'
自动拉回来——手动停止完全失效。
语义修正:
enabled = 期望运行状态, 是 sync loop 判断'该实例是否应该在跑'的唯一权威。
- stop_instance: enabled=False (手动停止, sync loop 不得自动重启)
- start_instance: enabled=True (手动启动, 否则下轮 sync 会把它当多余停掉)
- start 失败: enabled 保持 True (端口冲突常是暂时的, sync loop 自动重试)
测试:
+ tests/e2e_stop_semantics.py
stop 后等 2 个 loop 周期 (5s), 断言端口不被自动拉回 + DB.enabled=False;
start 后断言端口恢复 + DB.enabled=True + DB.running=True
本地 PASS
全套回归:
smoke tunnel / e2e lifecycle / e2e health / e2e sync loop / e2e stop semantics
全部 PASS
|
2026-08-11 00:07:31 +08:00 |
|
|
cnbugs
|
eba7ae831f
|
fix(socks5): 加后台 sync loop, 周期探活自动救活死 SOCKS5 实例
背景:
is_alive() 健康探活已就绪, 但 sync_instances 只能由 API 手动触发。
没人调 API 就没人探活, 死掉的 SOCKS5 实例一直挂着, DB.running 还是
true, 用户看到的就是'实例莫名停止'。这是最后一块拼图。
变更:
app.py
+ _start_sync_loop() 后台 daemon 线程, 周期调用 sync_instances
(默认 30s, SM_SYNC_INTERVAL 可调, SM_SYNC_LOOP_ENABLE
可关)。线程级单例, 多次 create_app 只启一次。
+ create_app 末尾调 _start_sync_loop + 初始 sync_instances, 保证
gunicorn worker 启动时就把实例拉起来
engine/instances.py
M is_alive() docstring 补充判定依据 (thread/server/is_serving)
测试:
+ tests/e2e_sync_loop.py create_app 启动 loop -> 插 DB 实例 -> loop 拉起
-> kill server socket -> loop 自动救活 + 换对象
本地 3 次连续运行全 PASS, 端口 ~4.5s 被救活
验证:
- smoke tunnel timeout: PASS
- e2e lifecycle (userpass + add_traffic): PASS
- e2e health check (sync_instances 探活): PASS
- e2e sync loop (后台自动救活): PASS
- app import: OK
|
2026-08-10 23:57:56 +08:00 |
|
|
cnbugs
|
74a68fcbd0
|
fix(socks5): 加 Socks5Server.is_alive() 健康探活, sync_instances 自动重启死实例
背景:
Socks5Server.running 是乐观标记, start() 之后到 stop() 之前一直 True。
但子线程 event loop 崩了/端口被外部抢占/worker 被 gunicorn 杀 等情况,
self.running 仍为 True, DB 里 inst.running=true 是谎言。
上次 40080 实例莫名停止就是这种状态。
变更:
+ Socks5Server.is_alive() thread.is_alive() + server.is_serving()
M InstanceManager.sync_instances 启动前先探活, 死的从 _instances 摘掉
让'启动缺失'循环用 DB 配置重建它
M inst.running = srv.is_alive() 不再用乐观的 srv.running
测试:
+ tests/e2e_socks5_lifecycle.py 完整 SOCKS5 userpass 生命周期, 拦住
_record_stats 里 await 同步方法的回归
+ tests/e2e_health_check.py 模拟 Socks5Server 死了, sync_instances
自动重启; 反向验证: 注释掉健康检查就 fail
验证:
- 正向 (修复在): lifecycle PASS, health PASS, smoke tunnel PASS
- 反向 (回滚修复): 两个 e2e 都正确 FAIL, 证明测试真的能抓回归
|
2026-08-10 23:45:29 +08:00 |
|
|
cnbugs
|
22b9427ca5
|
fix(socks5): 去掉 _record_stats 里对同步方法 add_traffic 的 await
回归: ee8c0b8 引入的 _forward timeout 修复没改 _record_stats,
但烟雾测试里 FakeUserService.add_traffic 误写成 async def 掩盖了
这个 bug。生产机 15:32:08 命中:
socks.engine: 记录统计失败: object NoneType can't be used in 'await'
gunicorn: [CRITICAL] WORKER TIMEOUT (pid:428355)
gunicorn: Error handling request (no URI read)
add_traffic 是 UserService 里的 def (非 async), 不能 await。错误地
await 一个 None 返回值会让 worker 在协程上下文里抛 TypeError,
被 _record_stats 的 except 吃掉, 但 worker 进入不可服务状态,
触发 30s gunicorn timeout, 表现就是 40080 实例莫名停止。
注意 log_event 是 async, 仍需 await; add_traffic 是 def, 不 await。
修法:
engine/server.py:472 去掉 await, 同步调用 add_traffic
tests/smoke_tunnel_timeout.py FakeUserService.add_traffic 改为
def, 模拟真实 UserService 签名,
防止烟雾测试再次漏掉此类 bug
线上已临时恢复 40080 (curl POST /api/instances/2/restart),
|
2026-08-10 23:35:30 +08:00 |
|
|
cnbugs
|
ee8c0b83db
|
fix(socks5): 隧道转发阶段补 idle timeout,防慢客户端耗尽 fd
之前 _forward() 直接 await src.read(TUNNEL_CHUNK),无 timeout。
已通过 SOCKS5 握手的客户端可以一直挂着不发数据,占住 fd 不放,
直到 LimitNOFILE=65535 才被内核拒。
握手/认证/请求阶段已经全部用 asyncio.wait_for + config.timeout,
但同一个 timeout 字段没覆盖 tunnel 阶段,语义不一致。
修复:
engine/server.py:381-407 _forward 每次 read 包 wait_for, 触发
TimeoutError 时 break 走 _tunnel 的 finally
清理 (关闭 writer, 取消对端 forward 任务)
验证 (tests/smoke_tunnel_timeout.py):
- 客户端只握手不进 tunnel, 服务端在 config.timeout 秒后关闭
- 反向: git stash 掉修复, 客户端永远不被关闭, 服务端报
'Task was destroyed but it is pending' — 证明修复前后行为差
异真实存在
models.Instance.timeout 注释: 说明该字段覆盖 tunnel 阶段
|
2026-08-10 23:28:46 +08:00 |
|