hermes - 💡(How to fix) Fix [Bug]: s6-log lock collision loops endlessly in multi-container gateway + dashboard shared volume setups

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Additional Logs / Traceback (optional)

Because both the gateway and dashboard containers share the /opt/data mount (to access the same SQLite database and user profiles/skills), they both execute s6-log targeting the exact same lock path. The first container locks the file successfully; the second container is immediately blocked with a Resource busy error, causing its s6-log service to crash and be continuously restarted by the container supervisor in a tight loop.

Root Cause

The dashboard container is trapped in an endless, rapid log-supervisor crash loop because it cannot acquire the lock on /opt/data/logs/gateways/default/lock (which is already held by the gateway container).

Fix Action

Fix / Workaround

For end-users facing this, the immediate workaround is to map the logging directory of the sidecar container to an in-memory tmpfs volume in docker-compose.yml:

    tmpfs:
      - /opt/data/logs:uid=1026,gid=100,mode=1777

Code Example

Host Environment: Synology DS224+ (Intel Celeron J4125, 10GB RAM)
Orchestration: Docker Compose
Mount Type: Shared Btrfs host volume bind-mount

---

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

Bug Description

Running the official gateway + dashboard stack on a shared data volume (necessary to keep SQLite state databases, dynamic skills, and config in sync) triggers an endless, sub-second s6-log lock crash loop in the dashboard sidecar container under v0.15.0 and v0.15.1.

Steps to Reproduce

  1. Set up a standard multi-container Docker Compose stack containing both gateway and dashboard services.
  2. Bind-mount the same host data folder to both containers: - /volume1/docker/hermes/data:/opt/data
  3. Launch the stack: docker compose up -d
  4. The gateway container boots first and claims the shared logs lock.
  5. The dashboard container boots second, fails to lock the shared path, and crashes s6-log.
  6. Inspect the dashboard logs: docker logs hermes-dashboard

Expected Behavior

Both containers should boot and execute their respective services (gateway and web dashboard) peacefully while sharing the same underlying data directory without locking conflicts or crash-loops.

Actual Behavior

The dashboard container is trapped in an endless, rapid log-supervisor crash loop because it cannot acquire the lock on /opt/data/logs/gateways/default/lock (which is already held by the gateway container).

This loop creates a continuous, high-frequency stream of disk writes on the host (rattling mechanical hard drives on Btrfs/ext4 systems continuously).

Affected Component

Other

Messaging Platform (if gateway-related)

No response

Debug Report

Host Environment: Synology DS224+ (Intel Celeron J4125, 10GB RAM)
Orchestration: Docker Compose
Mount Type: Shared Btrfs host volume bind-mount

Operating System

Synology DSM 7.2+ (Linux Kernel 5.10.x)

Python Version

3.11.9

Hermes Version

0.15.1 (v2026.5.29)

Additional Logs / Traceback (optional)

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

Root Cause Analysis (optional)

In Hermes v0.15.0, process supervision via s6-overlay was introduced. Inside the base image, s6-log is hardcoded to acquire a file-level lock on /opt/data/logs/gateways/default/lock on startup.

Because both the gateway and dashboard containers share the /opt/data mount (to access the same SQLite database and user profiles/skills), they both execute s6-log targeting the exact same lock path. The first container locks the file successfully; the second container is immediately blocked with a Resource busy error, causing its s6-log service to crash and be continuously restarted by the container supervisor in a tight loop.

Proposed Fix (optional)

Decouple the s6-log locking path from the shared user data directory, or make the lock file path container-specific or configurable via an environment variable.

For example, s6-log could lock /opt/data/logs/gateways/default/lock-<hostname> or use a local container path like /var/log that is not bound to a shared host volume.

For end-users facing this, the immediate workaround is to map the logging directory of the sidecar container to an in-memory tmpfs volume in docker-compose.yml:

    tmpfs:
      - /opt/data/logs:uid=1026,gid=100,mode=1777

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug]: s6-log lock collision loops endlessly in multi-container gateway + dashboard shared volume setups