Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,569 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c
Lĩnh vực
cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
C
Star
45.8k
Fork
3.8k
Merge trung bình
3 ngày 6 giờ
Pull request đã merge (30 ngày)
201

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DeusData/codebase-memory-mcp

Tất cả issue của DeusData/codebase-memory-mcp

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.