fix(docker): set S6_KEEP_ENV=1 to preserve container environment by ugoenyioha · Pull Request #33148 · NousResearch/hermes-agent

ugoenyioha · 2026-05-27T09:20:19Z

Summary

s6-overlay v3 strips the container's environment by default before exec'ing the main program (CMD). This causes all Kubernetes-injected env vars (MATTERMOST_TOKEN, MATTERMOST_URL, HERMES_HOME, HOME, provider API keys) to vanish by the time the hermes gateway process starts.

The gateway then fails to detect any messaging platforms because os.getenv() returns empty for every credential, producing:

WARNING gateway.run: No messaging platforms enabled.

Root Cause

The migration from tini (v2026.5.16) to s6-overlay on main changed the PID 1 from tini (which preserves env) to s6's /init (which strips env by default per the s6-overlay docs).

The #!/command/with-contenv shebang in s6 service scripts restores the env from /run/s6/container_environment/, but main-wrapper.sh (the CMD) uses plain #!/bin/sh and does NOT use with-contenv.

Fix

One line: ENV S6_KEEP_ENV=1 in the Dockerfile. This preserves the full container environment for the main program and all cont-init.d scripts.

Verification

Tested on a two-tenant Hermes deployment on Talos Kubernetes:

Without fix: HERMES_HOME=<UNSET>, MATTERMOST_TOKEN len=0, gateway reports "No messaging platforms enabled"
With fix: HERMES_HOME=/opt/data, MATTERMOST_TOKEN len=26, gateway detects and connects to Mattermost

Impact

This affects every Docker/Kubernetes deployment running from main since the s6-overlay migration. The v2026.5.16 release (tini-based) is not affected.

s6-overlay v3 strips the container's environment before execing the main program (CMD). This causes all Kubernetes-injected env vars (MATTERMOST_TOKEN, MATTERMOST_URL, HERMES_HOME, HOME, API keys) to vanish by the time the hermes gateway process starts. The gateway then fails to detect any messaging platforms because os.getenv() returns empty for every credential. v2026.5.16 used tini as PID 1 (no env stripping), so this was never an issue. The migration to s6-overlay on main introduced the regression. Fix: ENV S6_KEEP_ENV=1 in the Dockerfile, per the s6-overlay docs. This preserves the full container environment for the main program and all cont-init.d scripts.

alt-glitch · 2026-05-27T09:37:03Z

Related to merged #32412 which fixed s6-overlay env stripping using #!/command/with-contenv shebang on main-wrapper.sh and cont-init scripts. This PR takes a different approach — S6_KEEP_ENV=1 globally preserves the container environment. Both address the same root cause (#33004, #33001). Verify whether #32412's with-contenv approach already resolves this for K8s deployments, or if S6_KEEP_ENV=1 is still needed as a belt-and-suspenders fix.

smiggiddy · 2026-05-27T16:02:45Z

I'm still seeing issues on k8s even after using #32412

benbarclay · 2026-05-28T03:49:04Z

Thanks for chasing this down @ugoenyioha — your root-cause analysis is exactly right (s6-overlay v3 scrubs env before exec'ing CMD). The fix already landed on main via a different route: #32412 (commit 628aaea) changed docker/main-wrapper.sh's shebang from #!/bin/sh to #!/command/with-contenv sh, which sources /run/s6/container_environment/ per-script rather than globally preserving env. Same outcome with tighter blast radius (no global s6 behavior change). #33481 then extended the same with-contenv-sources-env-plus-explicit-HOME-reset pattern to the supervised dashboard and dynamic-gateway run scripts.

Closing as superseded — the deployment scenario you described should work on current main. Please re-open if you hit it on a freshly built image from latest main.

…NousResearch#34192) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem #2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem #3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem #4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…#34192) (#34382) #34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues #34192 raises that are NOT addressed by this PR: * Problem #2 (UID 1024 vs 10000 mismatch): already fixed by #33148 (S6_KEEP_ENV=1) and #32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem #3 (incompatible session formats): RFC for pluggable SessionDB is tracked in #23717. * Problem #4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The #34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: #34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…NousResearch#34192) (NousResearch#34382) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem NousResearch#2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem NousResearch#3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem NousResearch#4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…NousResearch#34192) (NousResearch#34382) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem #2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem #3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem #4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…NousResearch#34192) (NousResearch#34382) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem NousResearch#2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem NousResearch#3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem NousResearch#4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…NousResearch#34192) (NousResearch#34382) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem #2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem #3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem #4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…NousResearch#34192) (NousResearch#34382) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem NousResearch#2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem NousResearch#3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem NousResearch#4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

…NousResearch#34192) (NousResearch#34382) NousResearch#34192 reports Hostinger's 'Hermes WebUI' catalog crashes on startup with: /usr/bin/tini: No such file or directory The image moved from tini to s6-overlay as PID 1 (/init) earlier in 2026. Orchestration templates that still pin /usr/bin/tini as the entrypoint \u2014 like the Hostinger Hermes WebUI catalog \u2014 have no binary to exec and the container crashes immediately. Hermes has no control over the Hostinger catalog template, but we can make the image backward-compatible by symlinking /usr/bin/tini -> /init during the s6-overlay install step. External wrappers that exec /usr/bin/tini will land on the same s6-overlay reaper they would have landed on if they'd used the canonical /init entrypoint. The image's own ENTRYPOINT continues to be /init verbatim \u2014 the shim is purely for legacy external wrappers, not for the image's own runtime path. Once affected catalogs are updated, the symlink can be removed. Other issues NousResearch#34192 raises that are NOT addressed by this PR: * Problem #2 (UID 1024 vs 10000 mismatch): already fixed by NousResearch#33148 (S6_KEEP_ENV=1) and NousResearch#32412 (with-contenv shebangs). The Hostinger template likely needs to update its env-var propagation. * Problem #3 (incompatible session formats): RFC for pluggable SessionDB is tracked in NousResearch#23717. * Problem #4 (Telegram polling conflict): an operations problem on Hostinger's side, not in this codebase. This PR is scoped to the one issue that can be fixed inside Dockerfile: the missing /usr/bin/tini binary. Tests (3 in test_dockerfile_tini_compat_shim.py): - test_tini_compat_symlink_present Guard: the symlink line must exist in Dockerfile. - test_tini_compat_comment_explains_why The NousResearch#34192 anchor comment must be present so future readers know why the shim is there (avoid accidental removal). - test_entrypoint_still_init_not_tini Sanity check: ENTRYPOINT remains /init (s6-overlay). The shim is only for external wrappers. Refs: NousResearch#34192 Partial fix: addresses the immediate tini-binary crash. Catalog-side fixes still needed by Hostinger for the UID and session-format problems documented in the issue. Co-authored-by: Cursor <[email protected]>

ugoenyioha · 2026-07-26T18:32:35Z

Following up because @smiggiddy reported above that this is still happening on k8s after #32412, which suggests the two fixes aren't equivalent in scope.

Checking current main: with-contenv is per-script opt-in and currently appears in 7 places —

docker/main-wrapper.sh
docker/stage2-hook.sh
docker/cont-init.d/015-supervise-perms
docker/cont-init.d/02-reconcile-profiles
docker/s6-rc.d/main-hermes/run
docker/s6-rc.d/dashboard/run
docker/s6-rc.d/dashboard/finish

— and S6_KEEP_ENV appears nowhere in the Dockerfile or docker/.

So #32412 restores the environment for processes launched through those scripts, while S6_KEEP_ENV=1 disables the stage-1 scrub globally. Anything that doesn't enter through one of the seven still sees a scrubbed environment. That gap is easy to hit on k8s specifically, because overriding command:/args: in a PodSpec bypasses main-wrapper.sh altogether — the wrapper is where the fix lives, so a Deployment that sets its own command never gets it. The same applies to exec probes and any sidecar-invoked process.

That's consistent with what @smiggiddy is seeing, and it's a mechanism rather than a guess — but I want to be clear about the boundary of what I verified: I confirmed the scope difference from the source, not the specific failure on his cluster. The root-cause analysis @benbarclay confirmed is unchanged.

@smiggiddy — if you can post the PodSpec shape (specifically whether you set command:/args:) and which variables come back empty, that would pin it down. If it is the command:-override path, the targeted fix is narrower than this PR was: keep #32412's with-contenv approach and make the scrub-exemption cover the entry paths a PodSpec can substitute, rather than setting S6_KEEP_ENV=1 globally as this PR did.

Happy to open a focused PR on that once we know which path is failing. Not asking to un-close this one as-is — @benbarclay's objection to the global approach stands.

ugoenyioha · 2026-07-26T19:34:38Z

Correcting myself — I tested the mechanism I proposed above, and it does not hold.

I claimed the per-script nature of #32412 leaves a Kubernetes gap because overriding command:/args: in a PodSpec bypasses main-wrapper.sh. That is wrong on both halves:

args: does not bypass the wrapper — it is the CMD the wrapper wraps, so it gets with-contenv treatment.
command: replaces the image ENTRYPOINT entirely, so s6 never runs and there is no scrub to survive. Also not a gap.

Measured it rather than reasoning about it. Throwaway pod from an image that carries #32412, no command:, args: ["sleep","infinity"], one marker env var, and deliberately no S6_KEEP_ENV:

# 1. s6 saved the pod env for with-contenv to read
$ cat /run/s6/container_environment/PROBE_MARKER
marker-abc123

# 2. and the s6-STARTED CMD process actually has it
$ pid=$(pgrep -f '^sleep infinity' | head -1)
$ tr '\0' '\n' < /proc/$pid/environ | grep PROBE_MARKER
PROBE_MARKER=marker-abc123

So on a current image the pod environment survives the scrub without this PR's global switch, because main-wrapper.sh and the s6 service run scripts all carry the with-contenv shebang. #32412 is sufficient for the ordinary Kubernetes path, and @benbarclay's call to close this looks correct. I'd previously carried S6_KEEP_ENV=1 on a k8s deployment and assumed it was load-bearing; by this test it is simply vestigial, set before the image contained #32412.

@smiggiddy — that narrows your case to a few candidates, and the first is quick to rule out:

kubectl exec <pod> -- head -1 /opt/hermes/docker/main-wrapper.sh

If that prints #!/bin/sh rather than #!/command/with-contenv sh, your image predates #32412 (commit 628aaea) and an image bump is the fix, not this switch. If it does show with-contenv, then the process losing its environment is being started by something other than the wrapper or the s6 run scripts — worth identifying which one, since that would be a real gap and a much narrower fix than a global S6_KEEP_ENV.

Not arguing to reopen this. Just did not want a wrong mechanism left standing in the thread.

alt-glitch added type/bug Something isn't working P1 High — major feature broken, no workaround area/docker Docker image, Compose, packaging backend/docker Docker container execution labels May 27, 2026

benbarclay closed this May 28, 2026

benbarclay mentioned this pull request May 28, 2026

fix(docker): inject venv PATH into /etc/profile.d for login shells #33179

Closed

ChibiPaul mentioned this pull request May 28, 2026

Hostinger VPS: migration Hermes Agent → Hermes WebUI impossible (tini + UID mismatch + sessions) #34192

Closed

Bartok9 mentioned this pull request May 29, 2026

fix(docker): add /usr/bin/tini compatibility shim for legacy wrappers (#34192) #34382

Merged

ugoenyioha mentioned this pull request Jul 26, 2026

fix(docker): keep the venv on PATH in login shells #72197

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(docker): set S6_KEEP_ENV=1 to preserve container environment#33148

fix(docker): set S6_KEEP_ENV=1 to preserve container environment#33148
ugoenyioha wants to merge 1 commit into
NousResearch:mainfrom
ugoenyioha:fix/s6-keep-env

ugoenyioha commented May 27, 2026

Uh oh!

alt-glitch commented May 27, 2026

Uh oh!

smiggiddy commented May 27, 2026

Uh oh!

benbarclay commented May 28, 2026

Uh oh!

ugoenyioha commented Jul 26, 2026

Uh oh!

ugoenyioha commented Jul 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

ugoenyioha commented May 27, 2026

Summary

Root Cause

Fix

Verification

Impact

Uh oh!

alt-glitch commented May 27, 2026

Uh oh!

smiggiddy commented May 27, 2026

Uh oh!

benbarclay commented May 28, 2026

Uh oh!

ugoenyioha commented Jul 26, 2026

Uh oh!

ugoenyioha commented Jul 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants