[Priority: Low] [Bug/Ops] 上游 opencode temp .so 文件堆积与部署缓解跟踪

[liujuanjuan1984]

现象描述

在长时间运行环境中，系统提示 /tmp 磁盘空间不足。经过审计发现，/tmp (通常为 tmpfs，大小为 16G) 被占用了 15GB+。

占用详情如下：

• 文件数量: 约 3,390 个。
• 单个文件: ~4.3MB。
• 命名模式: /tmp/.*.so (例如 .589fe...-00000000.so)。
• 文件性质: ELF 64-bit LSB shared object，带有调试信息。

根本原因诊断

1. 会话配置过高: opencode-a2a-serve 的 SessionManager 默认设置了 session_cache_maxsize=10000 和 session_cache_ttl_seconds=3600。
2. 上游 LSP 行为: opencode serve 在处理这些会话的代码分析请求时，会启动 pyright-langserver (Node.js)。Node.js 在加载特定原生扩展时会在 /tmp 创建随机命名的临时 .so 文件。
3. 缓存堆积: 由于会话数量上限极高且存活时间长，且进程退出或会话切换时可能未触发物理文件的清理逻辑，导致了大量历史残留。

建议方案

为了防止 /tmp 空间再次耗尽，建议采取以下非激进措施：

1. 优化配置:
   • 调低 SESSION_CACHE_MAXSIZE (建议由 10,000 降至 500 - 1000)。
   • 调低 SESSION_CACHE_TTL_SECONDS (建议由 3600 降至 600 - 1200)。
2. 清理策略:
   • 在 opencode-a2a-serve 的退出逻辑或定期心跳检查中，识别并清理过期的 /tmp/.*.so 文件。
   • 或在 scripts/doctor.sh 等健康检查脚本中加入清理逻辑。

[liujuanjuan1984]

基于 2026-03-30 的 main 重新审查后，我认为这个 issue 的现象仍然合理，问题依然有效，但当前正文里的根因分析和建议方案需要按现状收口。

当前主干下的关键结论

1. /tmp 高占用作为运维问题本身依然成立，值得处理。
2. 但 issue 里把根因主要归到 SessionManager 默认 session_cache_ttl_seconds=3600 / session_cache_maxsize=10000，这在当前主干上已经不是默认生产路径：
   • 当前默认 A2A_TASK_STORE_BACKEND=database
   • create_app() 会先构造 session_state_repository
   • OpencodeAgentExecutor 再把该 repository 注入 SessionManager
   • 这意味着默认部署不会直接依赖那组 memory cache 默认值来决定 session retention
3. 当前默认路径更值得关注的，反而是 database session binding state 默认是 durable 的，而且没有 TTL / last-seen 清理策略。从仓内代码看：
   • build_session_state_repository() 默认返回 DatabaseSessionStateRepository
   • _SESSION_BINDINGS / _SESSION_OWNERS 表没有 updated_at / expires_at
   • 所以 issue 里“调低 SESSION_CACHE_*”并不能覆盖当前默认部署
4. 即使退回 memory backend，issue 里写的 SESSION_CACHE_* 也不是当前已经暴露出来的正式 settings/env knobs；目前它们仍是内部默认值/常量，不是可运维配置面。
5. “在服务退出逻辑、心跳检查或 scripts/doctor.sh 中扫描并删除 /tmp/.*.so”不建议作为主方案：
   • /tmp 是共享命名空间
   • 仓内当前没有可靠归属判定，无法安全证明这些匿名 .so 一定属于本实例
   • 这类 scavenger 更像高误伤风险的运维脚本，不像稳健的产品修复

更符合当前代码与上游能力的方向

我建议把这个 issue 的实现方向改成：

1. 优先做 session retention control，而不是 tmp 文件清道夫
   • 为默认 database backend 设计 session binding/session owner 的 retention / expiration / pruning 策略
   • 同时再决定 memory backend 是否需要额外暴露 maxsize/ttl 调优项
2. 把 upstream session disposal 纳入方案
   • OpenCode 官方 server 文档（2026-03-29 更新）已经公开 DELETE /session/:id
   • 如果本地 binding/session 被显式淘汰或过期，后续可以评估是否同步调用 upstream session delete，而不是只删本地映射
3. 文档化默认 durable 行为
   • 当前 guide 已说明默认 backend 是 database
   • 但没有专门强调“session binding / ownership 会跨进程保留，默认不会自动 TTL 回收”这一运维含义

和其它 open issues 的关系

高度相关的 open issue 我建议关注 #350：

• #350 当前在跟踪 session 管理面里的 create/delete/update/init
• 如果后续这里要引入显式 upstream session delete 或 session retention eviction，和 delete 的边界天然相关
• 但我不建议现在强行并一个分支一起做，除非本 issue 方案已经明确包含“显式 delete upstream session”的产品语义

除此之外，我没有看到其它需要和 #355 一起绑定开发的 open issues。#277（指标/追踪）是运维可观测性的邻接项，但不是同一修复面。

结论

• 这个 issue 应该继续保留并推进。
• 但建议把标题/描述里的主修复方向，从“调低 SESSION_CACHE_* + 清理 /tmp/.*.so”收敛成“为默认 durable session retention 增加可控回收策略，并评估 upstream session disposal”。
• 如果继续在这个分支实现，我建议先从评估并设计 database backend 的 session retention/pruning 方案开始，而不是先写 /tmp 文件清理逻辑。

[liujuanjuan1984]

补充当前结论，避免继续沿着本仓缓存实现误判：

1. 目前没有证据表明该现象主要来自 opencode-a2a 的 memory / database session state backend 差异。
2. 结合当前审查，问题更接近上游 opencode serve 在 headless 场景下仍会提取 OpenTUI 原生库到临时目录的行为；这与本仓 session binding 持久化不是同一层面的根因。
3. 已向上游官方仓库补充跟踪 issue：
   • Headless opencode serve still extracts libopentui.so into /tmp on every start, causing temp artifact buildup anomalyco/opencode#20043
4. 当前对本仓最合理的缓解不是增加 /tmp 清理逻辑，而是：
   • 在部署上游 opencode serve 时，使用专用 BUN_TMPDIR
   • 将该专用目录与系统共享 /tmp 隔离，便于后续定向清理
5. 本 issue 继续保持 open，用于跟踪：
   • 是否需要在本仓文档中明确记录 BUN_TMPDIR 部署建议
   • 是否需要在后续部署指南中补充该上游已知行为与运维缓解方式

[liujuanjuan1984]

补充收敛结论：需要把“清理宿主机 /tmp”从 adapter 职责里明确拿掉。

进一步明确：

• 不应在 opencode-a2a 服务退出逻辑、心跳检查、后台任务或 scripts/doctor.sh 中扫描并删除 /tmp/.*.so；
• 这类临时文件属于宿主机共享命名空间，当前仓库没有可靠归属判定，贸然清理存在误伤风险；
• 该现象更接近上游 opencode serve / Bun / Node 原生库提取行为的部署与运行时问题，而不是 adapter 应承担的系统清道夫职责。

因此，本 issue 如果继续保留，建议只跟踪两类动作：

• 文档化部署侧缓解方式，例如 BUN_TMPDIR / 专用临时目录建议；
• 评估本仓是否需要补充更明确的部署说明与运维告警，而不是在 adapter 内新增 /tmp 清理逻辑。