Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Daemon startup exceeds hardcoded 30s client-accept timeout on slow devices (Termux proot, aarch64)

オープン
  • 何か問題がありますか？
#2,569 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c
領域
cli

調査の方向性

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 の本文から書いたものです。

説明

editor/integration stability/performance ux/behavior

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:

  1. Environment: Termux proot-distro, Ubuntu 25.10 aarch64, install v0.11.0 to
    ~/.local/bin.
  2. Ensure clean rendezvous state (fresh CBM_RUNTIME_DIR).
  3. Command: echo '{}' | codebase-memory-mcp cli --quiet list_projects
  4. 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 .lock files, no socket; --cbm-daemon-internal
    visible from ~+15s
  • +30s: cbm-<hash>.sock + .sock.identity finally appear
  • +35s: CLI's 30s timer (started at +0s) already expired → exit 1
  • +40s: socket gone; daemon logged lifetime_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

  1. Make the client accept timeout (and ideally the daemon initial window)
    configurable, e.g. CBM_CLIENT_ACCEPT_TIMEOUT_MS.
  2. Harden socket publication/cleanup so a killed run cannot leave undeletable
    state behind.
主要言語
C
スター
45.8k
フォーク
3.8k
平均マージ
3日 16時間
マージ済み PR（30日）
203

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DeusData/codebase-memory-mcp のほかの issue

DeusData/codebase-memory-mcp の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。