hermes - 💡(How to fix) Fix [Bug]: s6-log lock collision in multi-container setup with shared /opt/data volume

When running multiple Hermes containers from the same image sharing a single /opt/data bind mount (e.g., a gateway container + dashboard container + custom profile container), the 02-reconcile-profiles cont-init script in every container registers s6 service slots for all profiles -- not just the one the container actually runs. This causes s6-log instances in the "wrong" containers to crash-loop with fatal: unable to lock errors.

Environment

- Hermes Agent: v0.14.0 (Docker image nousresearch/hermes-agent:latest)
- Docker Compose multi-container setup with shared /opt/data bind mount
- 3 containers: gateway (default profile), gateway (custom profile), dashboard

Each log sub-service runs:
sh
exec s6-setuidgid hermes s6-log 1 n10 s1000000 T "$log_dir"


s6-log tries to exclusively lock $HERMES_HOME/logs/gateways/<name>/lock. The first container to grab the lock wins; all others get:

s6-log: fatal: unable to lock /opt/data/logs/gateways/default/lock: Resource busy
s6-log: fatal: unable to lock /opt/data/logs/gateways/community/lock: Resource busy


Since s6-supervise restarts the log service on every crash, these errors repeat indefinitely in every container that doesn't own the gateway.

Report       https://paste.rs/OKDSr
  agent.log    https://paste.rs/5Kj7F
  gateway.log  https://paste.rs/RTWDF

The _register_service() helper creates the down marker on the gateway service directory, but the log/ sub-directory (which gets its own s6 service with its own run script) is never given a down marker.

Option A: Scope reconciliation to the active profile

Add an environment variable (e.g., HERMES_PROFILE=default) that 02-reconcile-profiles reads. Only register the s6 slot for the profile matching $HERMES_PROFILE. The dashboard container, which runs no gateway at all, could set HERMES_PROFILE=_none or a new env var like HERMES_SKIP_RECONCILE=1 to skip reconciliation entirely.

Option B: Add down markers to log sub-services

After _register_service() creates the service directory with a down marker on the main service, also create a down marker in the log/ sub-directory. This prevents the log sub-service from starting when the gateway itself is intentionally down. This is a smaller change but doesn't prevent the unnecessary service slot creation.

Option C: Both A and B

Option A prevents unnecessary slot creation; Option B is a safety net for any case where a gateway slot is created but shouldn't auto-start its logger.

Workaround

The errors are noisy but non-functional -- gateways and the dashboard continue to work correctly. The s6-log crash loops consume negligible resources. No production impact beyond log spam.