docs(artpipe runbook): §2 bootstrap shell command launches the .NET worker instead of bash #472

Closed
opened 2026-07-11 04:48:34 +00:00 by spikerj · 1 comment
Owner

Summary

The ArtPipe SERVER cutover runbook (spikersoft-infrastructure/docs/artpipe-server-cutover-runbook.md §2) tells operators to bootstrap model venvs inside a worker container with:

docker run --rm -it \
  -v /mnt/fusionio/spikersoft/art_pipe:/opt/art_pipe \
  git.spikersoft.com/spikerj/spikersoft-artpipe-processor:latest bash

This does not open a shell. The image has ENTRYPOINT ["dotnet", "SpikerSoft.EventHandlers.ArtPipeProcessor.dll"], so the trailing bash is passed as an argument to the entrypoint — the full .NET worker boots, immediately crashes with BrokerUnreachableException (a plain docker run isn't on the rabbitmq overlay, so the hostname doesn't resolve), and the container exits. An operator who pasted the runbook block then has the follow-up commands fall through to the host shell, where python3 bootstrap.py fails with the host interpreter (ensurepip is not available / missing python3.12-venv) and litters a half-built .venv in the checkout — exactly what happened in production on 2026-07-11.

A second gap: the image runs as the non-root app user, while the prod checkout at /mnt/fusionio/spikersoft/art_pipe is root-owned (cloned with sudo), so even a correct shell would fail writing .venv / models/*/venv without --user root.

Fix

Update §2's command to:

docker run --rm -it \
  --entrypoint bash \
  --user root \
  -v /mnt/fusionio/spikersoft/art_pipe:/opt/art_pipe \
  git.spikersoft.com/spikerj/spikersoft-artpipe-processor:latest

and add a short note explaining the entrypoint/user gotchas and that the inner cd /opt/art_pipe && python3 bootstrap.py ... commands must be typed inside the container shell (not pasted together with the docker run), plus cleanup guidance for a stray host-built .venv.

Repo: spikersoft-infrastructure

## Summary The ArtPipe SERVER cutover runbook (`spikersoft-infrastructure/docs/artpipe-server-cutover-runbook.md` §2) tells operators to bootstrap model venvs inside a worker container with: ``` docker run --rm -it \ -v /mnt/fusionio/spikersoft/art_pipe:/opt/art_pipe \ git.spikersoft.com/spikerj/spikersoft-artpipe-processor:latest bash ``` This does **not** open a shell. The image has `ENTRYPOINT ["dotnet", "SpikerSoft.EventHandlers.ArtPipeProcessor.dll"]`, so the trailing `bash` is passed as an *argument* to the entrypoint — the full .NET worker boots, immediately crashes with `BrokerUnreachableException` (a plain `docker run` isn't on the `rabbitmq` overlay, so the hostname doesn't resolve), and the container exits. An operator who pasted the runbook block then has the follow-up commands fall through to the **host** shell, where `python3 bootstrap.py` fails with the host interpreter (`ensurepip is not available` / missing `python3.12-venv`) and litters a half-built `.venv` in the checkout — exactly what happened in production on 2026-07-11. A second gap: the image runs as the non-root `app` user, while the prod checkout at `/mnt/fusionio/spikersoft/art_pipe` is root-owned (cloned with sudo), so even a correct shell would fail writing `.venv` / `models/*/venv` without `--user root`. ## Fix Update §2's command to: ``` docker run --rm -it \ --entrypoint bash \ --user root \ -v /mnt/fusionio/spikersoft/art_pipe:/opt/art_pipe \ git.spikersoft.com/spikerj/spikersoft-artpipe-processor:latest ``` and add a short note explaining the entrypoint/user gotchas and that the inner `cd /opt/art_pipe && python3 bootstrap.py ...` commands must be typed inside the container shell (not pasted together with the `docker run`), plus cleanup guidance for a stray host-built `.venv`. Repo: `spikersoft-infrastructure`
Author
Owner

Resolved in spikersoft-infrastructure PR #19 (merged): runbook §2 bootstrap command now uses --entrypoint bash + --user root so it launches a shell instead of the .NET worker. Closing.

Resolved in spikersoft-infrastructure PR #19 (merged): runbook §2 bootstrap command now uses --entrypoint bash + --user root so it launches a shell instead of the .NET worker. Closing.
Sign in to join this conversation.