Skip to content

v1.0.11 — 幽灵在线定位：serve() 有界化 acceptor + 生命周期诊断

Choose a tag to compare

View all tags
@EUForest EUForest released this 03 Sep 06:24
· 1 commit to main since this release
v1.0.11
7eff21a

定位版（诊断 + 有界化硬化）

前三版（v1.0.8/9/10）都在修 run_session_io（reader），但线上实证证明打偏了：
v1.0.10 已部署，客户端跑完 fast.com 断开后，节点侧入站连接=0（reader 已结束），
却仍上报「在线 1」逾 3 分钟、且残留 1 条出站中继 —— 说明 serve() 没返回、
OnlineGuard 没 drop、retire 没跑，卡点在 reader 之外。

本版做两件事：

  1. serve() 不再无限等 acceptor：serve()=join!(reader, acceptor) 要两个都
    结束才返回。reader（帧循环）在 carrier 关闭时结束，但 acceptor 靠 mux actor
    结束才退，actor 在「接收积压无消费者」时可能永不结束、accept_stream 永久阻塞，
    把 serve() 永久挂住。现在 reader 结束后给 acceptor 一个**有界宽限（2s）**自然收尾，
    超时即中止。健康会话亚秒级自然结束、无行为变化。
  2. 三条低基数诊断日志：reader 结束 / acceptor 自然结束(或被中止) / serve 返回。
    下次复现即可判定到底卡在 reader、acceptor 还是 serve 之后。

复测请求（关键）

升级后请再走一遍：连韩国 → fast.com → 断开 → 等 3~4 分钟。然后把这两段发我：

ssh root@3.36.107.43 "journalctl -u dbk-node --no-pager -n 200 | grep -E '会话IO|carrier：|在线上报' | tail -30"
ssh root@3.36.107.43 "cat /etc/daybreak/VERSION; ss -tnp | grep dbk-node | grep -c ESTAB"

日志会直接告诉我们：若在线归零了 → 本版修好了（卡的是 acceptor）；若仍是 1，
日志里缺哪条（reader/acceptor/serve）就精确指出真正的挂点，我据此补最终修复 + 回归测试。

产物

文件 架构
dbk-node-x86_64-unknown-linux-gnu.tar.gz x86_64 / amd64
dbk-node-aarch64-unknown-linux-gnu.tar.gz aarch64 / arm64
Assets 6
Loading