Daemon startup exceeds hardcoded 30s client-accept timeout on slow devices (Termux proot, aarch64)
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with the 30000 ms client accept timeout and the daemon's initial_window_expired lifetime logic, which the report says race on slow hardware. Reproduce with a fresh CBM_RUNTIME_DIR and echo '{}' | codebase-memory-mcp cli --quiet list_projects. Done would mean the first connection succeeds on a slow device or the timeout is configurable, but the issue also asks for socket cleanup changes, so scope needs maintainer input first.
由索引模型根据 Issue 内容生成。
描述
Environment
- Version:
codebase-memory-mcp 0.11.0 - Platform: Linux (arm64)
- Install channel: GitHub release archive / install.sh
- Binary variant: standard
(codebase-memory-mcp-linux-arm64-portable.tar.gz, release v0.11.0)
Additional context: Termux proot-distro, Ubuntu 25.10 (Questing), aarch64,
glibc 2.42, 8 CPUs, ~5.6 GB RAM. Client: opencode 1.18.35 (MCP stdio), but
also reproduced with cli directly. Installed to ~/.local/bin via
install -y --force --skip-config after manual download (the one-line
curl | bash stalls on this device's slow network).
What happened, and what did you expect?
On this device, every daemon-backed operation fails — both cli <tool> and
MCP stdio mode. The daemon needs ~28–30s+ just to publish its IPC listener,
while the client gives up at exactly 30s, so the handshake never succeeds. I
expected the client to wait long enough (or the timeout to be configurable)
so the first connection succeeds on slower devices.
Actual error (every attempt):
codebase-memory-mcp: CBM daemon is active or starting but could not accept this client within 30000 ms
--version, --help, and config list/get/set work fine — only
daemon-backed paths fail.
Reproduction
No repository needed — this fails before any indexing, on daemon startup:
- Environment: Termux proot-distro, Ubuntu 25.10 aarch64, install v0.11.0 to
~/.local/bin. - Ensure clean rendezvous state (fresh
CBM_RUNTIME_DIR). - Command:
echo '{}' | codebase-memory-mcp cli --quiet list_projects - Result: exit 1 with the 30s accept-timeout error above.
Expected: the project list (empty store is fine).
Timing evidence from polling the rendezvous dir during a single run:
+5s … +25s: only.lockfiles, no socket;--cbm-daemon-internal
visible from ~+15s+30s:cbm-<hash>.sock+.sock.identityfinally appear+35s: CLI's 30s timer (started at +0s) already expired → exit 1+40s: socket gone; daemon loggedlifetime_end reason=initial_window_expired
The race is lost identically on 6+ single attempts. Page cache is warm (cat
of the 286 MB binary takes ~1.6s), so this is startup work under proot, not
disk I/O. These did not change the outcome: clean rendezvous dir,
watcher_enabled=false, ui_enabled=false, CBM_WORKERS=1,
CBM_SEMANTIC_ENABLED=0, CBM_LSP_DISABLED=1, CBM_MEM_BUDGET_MB=512.
(I grepped the binary — no CBM_* timeout override exists today.)
Logs
Daemon log tail (typical run):
level=info msg=mem.init budget_mb=1422 total_ram_mb=5689 source=ram_fraction
level=info msg=watcher.disabled reason=config
level=info msg=daemon.start version=0.11.0 pid=25193 cache_fingerprint=aaefd8b8489b6c3cc7b9030f7d7e19d59e3e2dcb328def3cd68506085c1f3e0f memory_budget_bytes=1491437568 physical_job_limit=4 worker_memory_budget_bytes=1491437568
level=info msg=daemon.lifetime_end reason=initial_window_expired
level=info msg=daemon.runtime_stopping reason=service_stop
level=info msg=daemon.stop
Secondary observation: after timeout-killed runs, the rendezvous dir can hold
a dangling symlink that is undeletable under proot (ls shows
l??????????, rm/python os.unlink → ENOENT, rm -rf dir →
"Directory not empty"). Later runs then fail with listen_failed stage=pending_publication / stable_publication or pre-coordination or unverified CBM generation is active until a fresh CBM_RUNTIME_DIR is used.
Diagnostics trajectory
Happy to provide (CBM_DIAGNOSTICS=1 run) on request — let me know exactly
which scenario to capture.
Project scale
n/a (fails before any indexing).
Confirmations
- I searched existing issues and this is not a duplicate. (Related but
different: #52 SQLite lock contention on large projects, #46/#49 memory/OOM
— those are post-indexing issues; this is a startup-handshake timeout with
an empty store.) - My reproduction uses shareable code — no repository or proprietary code
involved.
Request
- Make the client accept timeout (and ideally the daemon initial window)
configurable, e.g.CBM_CLIENT_ACCEPT_TIMEOUT_MS. - Harden socket publication/cleanup so a killed run cannot leave undeletable
state behind.
- 主要语言
- C
- 星标
- 45.8k
- 派生
- 3.8k
- 平均合并
- 3 天 6 小时
- 30 天内合并 PR
- 201
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
DeusData/codebase-memory-mcp 的其他 Issue
-
Generated Pi extension (cbmem.ts) breaks Gemini/Antigravity: Type.Union of Type.Literal serializes to anyOf/const可能已有人在做 @divakantpandey 今天认领。 未关闭bug editor/integration
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2787 · 1 条评论 ·
维护者通常 2 天内回复
-
editor/integration parsing/quality
难度 2/5 1-3 小时 新手友好度 68/100
DeusData/codebase-memory-mcp#2286 ·
维护者通常 2 天内回复
-
install writes an unsupported `args` key into the Claude Code SubagentStart hook, so it never runs未关闭bug editor/integration priority/high stability/performance ux/behavior
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2239 · 1 条评论 ·
维护者通常 2 天内回复
-
bug priority/high ux/behavior
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2232 · 2 条评论 ·
维护者通常 2 天内回复
-
documentation editor/integration parsing/quality priority/normal
难度 2/5 1-3 小时 新手友好度 85/100
DeusData/codebase-memory-mcp#2169 ·
维护者通常 2 天内回复
查看 DeusData/codebase-memory-mcp 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
yunusemreyl/omen-space#337 ·
维护者通常 1 天内回复
-
dependency component: oneMKL module: dpclang
难度 2/5 1-3 小时 新手友好度 82/100
intel/torch-xpu-ops#5880 ·
维护者通常 2 天内回复