Hermes S6 Container Supervision — Modify or debug s6 services in the Hermes Docker image
Hermes S6 Container Supervision — Modify or debug s6 services in the Hermes Docker image
Start with meaning, then move to detail.
This lesson explains Hermes S6 Container Supervision — Modify or debug s6 services in the Hermes Docker image as part of Hermes internals and extension points. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect Skill metadata, Reference: full SKILL.md, When to use this skill, then verify failure modes and version compatibility.
Know Python, Git, and basic project structure before changing code.
A clear outcome before you read.
- Understand Hermes S6 Container Supervision — Modify or debug s6 services in the Hermes Docker image without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
Short definitions before the details.
- Gateway
- The process that connects Hermes to channels such as Telegram or Discord and routes messages.
- Skill
- An instruction bundle that teaches Hermes a repeatable workflow without necessarily adding an external service.
Modify or debug s6 services in the Hermes Docker image
What does the source say, and in what order?
- 01Skill metadata
Start here to understand the core idea or structure.
- 02Reference: full SKILL.md
Read this after the foundation, then connect it to the previous step.
- 03When to use this skill
Read this after the foundation, then connect it to the previous step.
- 04Architecture at a glance
Read this after the foundation, then connect it to the previous step.
- 05Key files
Read this after the foundation, then connect it to the previous step.
- 06Why Architecture B (CMD as main program, not s6-supervised)
Read this after the foundation, then connect it to the previous step.
- 07Quick recipes
Read this after the foundation, then connect it to the previous step.
- 08Verify s6 is PID 1 in a running container
Read this after the foundation, then connect it to the previous step.
- 09Inspect a profile gateway service
Read this after the foundation, then connect it to the previous step.
- 10Bring a service up/down manually
Finish here to verify the result and special cases.
Copy only after you understand the effect.
/init ← PID 1 (s6-overlay v3.2.3.0)
├── cont-init.d ← oneshot setup, runs as root
│ ├── 01-hermes-setup ← docker/stage2-hook.sh
│ │ ├── UID/GID remap
│ │ ├── chown /opt/data
│ │ ├── chown /opt/data/profiles (every boot)
│ │ ├── seed .env / config.yaml / SOUL.md
│ │ └── skills_sync.py
│ └── 02-reconcile-profiles ← hermes_cli.container_boot
│ ├── chown /run/service (hermes-writable for runtime register)
│ └── walk $HERMES_HOME/profiles/<name>/gateway_state.json
│ → recreadocker exec <c> sh -c 'cat /proc/1/comm; readlink /proc/1/exe'
# Expect: s6-svscan or init / /package/admin/s6/.../s6-svscan# /command/ isn't on docker-exec PATH — use absolute path
docker exec <c> /command/s6-svstat /run/service/gateway-<name>
# "up (pid …) … seconds" → running
# "down (exitcode N) … seconds, normally up, want up, …" → s6 wants it up but the process keeps exiting (crash loop)
# "down … normally up, ready …" → user stopped itRead the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.