hermes - 💡(How to fix) Fix [Bug]: Docker terminal sandboxes fail to start for s6 /init images

Official PRs (…)
ON THIS PAGE

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

Docker-backed terminal sandboxes fail to start for images that already use s6 /init as PID 1, which makes terminal-tool commands fail with a generic container ... is not running error. Before the local hotfix, the container died during startup and terminal commands failed with a daemon-level "container is not running" error.

Root Cause

The Docker environment logic currently assumes it can always:

  • add Docker --init
  • mount /run as --tmpfs /run:rw,noexec,nosuid,size=64m

That is not valid for images that already use s6 /init as PID 1. Those images need:

  • no extra Docker --init
  • an executable /run, because s6 stage0 later executes from /run/s6/...

The relevant local fix was in tools/environments/docker.py.

Fix Action

Fix / Workaround

Actual Behavior

Before the local hotfix, the container died during startup and terminal commands failed with a daemon-level "container is not running" error.

If useful, I can turn the validated local hotfix into a PR.

Code Example

from tools.environments.docker import DockerEnvironment

env = DockerEnvironment(
    image='hermes-agent:latest',
    cwd='/root',
    timeout=60,
    cpu=1,
    memory=1024,
    disk=0,
    persistent_filesystem=False,
    task_id='smoke-hermes-agent-latest',
    volumes=[],
    forward_env=[],
    env={},
    host_cwd=None,
    auto_mount_cwd=False,
    run_as_host_user=False,
    extra_args=[],
    persist_across_processes=False,
)
print(env.execute('echo hermes-smoke-ok'))

---

/package/admin/s6-overlay-3.2.3.0/libexec/stage0: 83: exec: /run/s6/basedir/bin/init: Permission denied
RAW_BUFFERClick to expand / collapse

Bug Description

Docker-backed terminal sandboxes fail to start for images that already use s6 /init as PID 1, which makes terminal-tool commands fail with a generic container ... is not running error.

In the reproduced case, Hermes starts a fresh hermes-agent:latest sandbox with both Docker --init and a noexec tmpfs on /run. That breaks s6 startup in two stages:

  1. Docker --init conflicts with an image that already has /init as its entrypoint.
  2. After skipping Docker --init, s6 still fails because it needs to exec /run/s6/basedir/bin/init, but /run is mounted noexec.

Steps to Reproduce

  1. Use the Docker terminal backend with hermes-agent:latest (or another image whose entrypoint is /init).
  2. Trigger any terminal-tool command that provisions a fresh sandbox.
  3. Observe that the container exits immediately and the terminal tool reports that the container is not running.

A minimal local smoke repro after sandbox creation was:

from tools.environments.docker import DockerEnvironment

env = DockerEnvironment(
    image='hermes-agent:latest',
    cwd='/root',
    timeout=60,
    cpu=1,
    memory=1024,
    disk=0,
    persistent_filesystem=False,
    task_id='smoke-hermes-agent-latest',
    volumes=[],
    forward_env=[],
    env={},
    host_cwd=None,
    auto_mount_cwd=False,
    run_as_host_user=False,
    extra_args=[],
    persist_across_processes=False,
)
print(env.execute('echo hermes-smoke-ok'))

Expected Behavior

Fresh Docker sandboxes should stay up, initialize correctly, and execute terminal commands normally.

Actual Behavior

Before the local hotfix, the container died during startup and terminal commands failed with a daemon-level "container is not running" error.

After removing Docker --init, the failure became explicit in container logs:

/package/admin/s6-overlay-3.2.3.0/libexec/stage0: 83: exec: /run/s6/basedir/bin/init: Permission denied

The container exited with code 126.

Affected Component

  • Tools (terminal, Docker sandbox environment)

Messaging Platform

  • N/A (CLI only)

Operating System

Windows host with Docker backend

Python Version

Reproduced locally with Python 3.11.14

Hermes Version

Reproduced on the repository's current main branch lineage (main at 75cd420b3ba1b83185020c6d4506d7cc53b12e2b when tested).

Root Cause Analysis

The Docker environment logic currently assumes it can always:

  • add Docker --init
  • mount /run as --tmpfs /run:rw,noexec,nosuid,size=64m

That is not valid for images that already use s6 /init as PID 1. Those images need:

  • no extra Docker --init
  • an executable /run, because s6 stage0 later executes from /run/s6/...

The relevant local fix was in tools/environments/docker.py.

Proposed Fix

Detect images whose entrypoint is /init and, for those images:

  • skip Docker --init
  • mount /run with exec instead of noexec

I validated that locally with:

  • a focused regression test in tests/tools/test_docker_environment.py
  • a fresh hermes-agent:latest smoke test that successfully returned hermes-smoke-ok

Additional Context

I did a duplicate search for likely matches before filing and did not find one.

If useful, I can turn the validated local hotfix into a PR.

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]: Docker terminal sandboxes fail to start for s6 /init images