From 981fc96ec5eb63331d4570622317ac50bc8c0e2d Mon Sep 17 00:00:00 2001 From: joelteply Date: Sat, 30 May 2026 12:44:28 -0500 Subject: [PATCH] fix(install): pre-create ~/.continuum/sockets before docker compose up MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit continuum-core's Dockerfile creates /root/.continuum/sockets at image build time, but docker-compose.yml mounts the host's ~/.continuum onto /root/.continuum at container start. The mount overlays the image's directory tree — the sockets/ subdir created at build is invisible inside the running container. continuum-core then tries to bind its IPC socket at /root/.continuum/sockets/continuum-core.sock, which fails with "IPC server error: No such file or directory (os error 2)" because the parent dir doesn't exist. Symptom: continuum-core never goes healthy → node-server's depends_on (condition: service_healthy) fails → docker compose up exits 1 with "dependency failed to start: container continuum-core-1 is unhealthy". Concrete trace from canary install-smoke for PR #1480 today: 17:40:25 — All 28 modules initialized, tick loops started 17:40:25 — ❌ IPC server error: No such file or directory (os error 2) 17:40:26 — Container Error / Waiting → Healthcheck never passes install.sh exits at "start support services" phase This bug has been silently blocking install-smoke for any docker-stack- touching PR; the previous 25-min cargo-build timeout was masking it because the install never got far enough to discover the socket issue. Now that PR #1480's precheck + canary-default routing makes the run fast, the underlying problem surfaces in 3 minutes with a clear error. Fix: pre-create the host-side directory tree (sockets/, jtag/data/, jtag/logs/) BEFORE compose up. This way the bind mount delivers a populated /root/.continuum to the container and continuum-core can bind its socket on first start. This is install.sh-side, not Dockerfile-side, because the mount is the overlaying layer — image-build mkdirs are hidden by the bind. The canonical fix is to mkdir on the host (which is what gets mounted). Co-Authored-By: Claude Opus 4.7 --- install.sh | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/install.sh b/install.sh index 4e1e3199d..3fe4324aa 100644 --- a/install.sh +++ b/install.sh @@ -777,7 +777,19 @@ mod_jtag_bin_link "$INSTALL_DIR/src/jtag" # ── 4. Configuration ─────────────────────────────────────── PHASE="configuration" -mkdir -p "$CONTINUUM_DATA" +# Pre-create the directories the docker mount overlays. The continuum-core +# Dockerfile does `RUN mkdir -p /root/.continuum/sockets …` but the +# compose `~/.continuum:/root/.continuum` mount overlays that with the +# HOST's ~/.continuum at container start — so any subdir created at image +# build time becomes invisible inside the container. continuum-core then +# fails to bind its IPC socket with "IPC server error: No such file or +# directory (os error 2)" and the healthcheck never goes green, blocking +# the whole stack (continuum-core unhealthy → node-server's depends_on +# fails → compose up exits 1). Caught 2026-05-30 on carl-install-smoke +# of #1480; the canary image healthcheck regression had been silently +# blocking install-smoke for any install touching the docker stack. +mkdir -p "$CONTINUUM_DATA" "$CONTINUUM_DATA/sockets" \ + "$CONTINUUM_DATA/jtag/data" "$CONTINUUM_DATA/jtag/logs" CONFIG_FILE="$CONTINUUM_DATA/config.env" if [ ! -f "$CONFIG_FILE" ]; then