fix(templates): populate /run/s6/container_environment when the entrypoint is PID 1 (#3013)

Add-ons that override the base image's ENTRYPOINT ["/init"] with
ENTRYPOINT ["/usr/bin/env"] plus CMD ["/ha_entrypoint.sh"] never run s6-overlay's
stage 1, so nothing creates /run/s6/container_environment. `with-contenv` empties
the environment and repopulates it from that directory, which means every script
carrying a #!/usr/bin/with-contenv shebang outside the three globs whose shebang
ha_entrypoint.sh rewrites either exits non-zero before its first line of logic
(directory missing: s6-envdir errors) or runs against whatever a cont-init script
happened to leave there.

Measured in a running add-on of this repo whose PID 1 is /ha_entrypoint.sh: a
with-contenv script saw 16 environment variables where the entrypoint has 110, with
SUPERVISOR_TOKEN among the missing. Neither failure prints anything, so all that
surfaces is whatever the caller makes of a non-zero exit — a Docker HEALTHCHECK
reading "unhealthy" for eight months, in the case that prompted this. Cron jobs,
user-facing CLI wrappers and the user's own script.sh share the blind spot.

Dump the environment here instead, with s6-dumpenv, which is what stage 1 would
have done. Guarded on being PID 1 and on with-contenv existing, so it neither runs
under /init — where stage 1 already wrote the directory — nor warns in images that
have no with-contenv to fix.

Filled in a sibling directory and renamed into place rather than written live. A
half-populated envdir is worse than an absent one: s6-envdir accepts it, so a
with-contenv script starts and runs against an environment quietly missing
SUPERVISOR_TOKEN, where an absent one stops it at its shebang. A HEALTHCHECK can run
alongside PID 1, and rename(2) means such a reader sees the directory either absent
or complete. Measured with a racing poller over 664 samples: only 0 or 110 entries,
never a partial count.

The directory is cleared first rather than written over. /run is not a tmpfs in
these containers, so an image layer could persist entries there, and merging into
them would leave variables PID 1 does not have, including a stale SUPERVISOR_TOKEN.
A failed rm aborts the attempt, since mkdir -p accepts a surviving
symlink-to-directory and would let the dump follow it.

A failed seed leaves the directory absent, which is how this already fails today, so
the failure mode is unchanged rather than newly degraded — but it now says so.

Placed after the shebang probe on purpose. The probe's first candidate is
"/command/with-contenv bashio" and it fails today in exactly these add-ons, so the
probe falls through to "/usr/bin/env bashio". Seeding earlier would make that first
candidate start succeeding and flip the shebang of every cont-init and service
script that lands here, which is a much larger change than this fixes.

Refs #3006

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

.templates/ha_entrypoint.sh

@@ -168,6 +168,59 @@ if [ -z "$shebang" ]; then
   exit 1
 fi
 
+#####################################
+# Seed the s6 container environment #
+#####################################
+
+# s6-overlay's stage 1 dumps the container's environment into /run/s6/container_environment, and
+# `with-contenv` reads it back (emptyenv -p; s6-envdir). Add-ons that override the base image's
+# ENTRYPOINT ["/init"] with ENTRYPOINT ["/usr/bin/env"] plus CMD ["/ha_entrypoint.sh"] never run
+# stage 1, so nothing creates that directory and every #!/usr/bin/with-contenv script outside the
+# three globs whose shebang is rewritten below either exits non-zero before its first line
+# (directory missing: s6-envdir errors) or runs against whatever a cont-init script happened to
+# leave there -- measured at 16 variables instead of 110, SUPERVISOR_TOKEN among the missing.
+# Neither says anything, so all that surfaces is what the caller makes of it: a HEALTHCHECK
+# reporting "unhealthy", a cron job doing nothing. So dump the environment here instead.
+#
+# Deliberately after the shebang probe above, not next to the other PID 1 setup: the probe's first
+# candidate is "/command/with-contenv bashio" and it fails today in exactly these add-ons, so the
+# probe falls through to "/usr/bin/env bashio". Seeding earlier would make that candidate start
+# succeeding and flip the shebang of every cont-init and service script here, so scripts launched
+# directly would lose what an earlier sourced script exported -- a far larger change than this.
+#
+# It does switch on two dormant writes: 00-global_var.sh and 01-config_yaml.sh push their values
+# into the envdir, but only `if [ -d ]`. That is what those lines are for, and it means out-of-glob
+# scripts now see the user's configured options too.
+
+S6_CONTAINER_ENV="/run/s6/container_environment"
+
+# Only when this script is PID 1 -- under /init it is the stage-2 hook and stage 1 has already
+# written the directory -- and only where with-contenv exists to care.
+if $PID1 && { [ -x /command/with-contenv ] || [ -x /usr/bin/with-contenv ]; }; then
+  # Filled in a sibling and renamed into place, never written to live. A half-populated envdir is
+  # worse than an absent one: s6-envdir accepts it, so a with-contenv script starts and runs
+  # against an environment quietly missing SUPERVISOR_TOKEN, where an absent one stops it at its
+  # shebang. rename(2) means a concurrent reader -- a HEALTHCHECK can run alongside PID 1 -- sees
+  # the directory either absent or complete, never mid-dump.
+  #
+  # Cleared rather than written over: /run is not a tmpfs here, so an image layer can persist
+  # entries, and writing name by name would merge into them and leave variables PID 1 does not
+  # have, a stale SUPERVISOR_TOKEN among them. A failed rm has to abort the chain, because mkdir -p
+  # accepts a surviving symlink-to-directory and would let the dump follow it. rm does not traverse
+  # a symlink, but it would empty anything bind-mounted at this exact path -- not a configuration
+  # any add-on uses, and not one s6 would tolerate either.
+  if rm -rf "$S6_CONTAINER_ENV" "$S6_CONTAINER_ENV.tmp" && mkdir -p "$S6_CONTAINER_ENV.tmp" &&
+    s6-dumpenv -- "$S6_CONTAINER_ENV.tmp" && mv "$S6_CONTAINER_ENV.tmp" "$S6_CONTAINER_ENV"; then
+    echo "Populated $S6_CONTAINER_ENV for with-contenv"
+  else
+    # Leaves the directory absent, which is exactly how this fails today -- so the failure mode is
+    # unchanged, not newly degraded. Never fatal, a read-only /run must still let the add-on boot,
+    # but never silent either, since the shebang failure it leaves behind says nothing on its own.
+    rm -rf "$S6_CONTAINER_ENV" "$S6_CONTAINER_ENV.tmp" 2>/dev/null || true
+    echo -e "\e[38;5;214m$(date) WARNING: could not populate $S6_CONTAINER_ENV; scripts with a with-contenv shebang will fail at their shebang, as they did before this was attempted\e[0m"
+  fi
+fi
+
 ####################################
 # Bashio library for source fallback
 ####################################

portainer_agent/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.44.0.1 (2026-08-24)
+
+- Rebuild to pick up a fix in the shared entrypoint: when `ha_entrypoint.sh` runs as PID 1, as it does in this add-on, it now populates `/run/s6/container_environment`, so a script carrying a `#!/usr/bin/with-contenv` shebang gets a populated environment including `SUPERVISOR_TOKEN` instead of failing at its shebang. Nothing shipped in this add-on still uses that shebang (the healthcheck moved to plain bash in 2.44.0), so this changes nothing about the agent itself; it matters for a `script.sh` added by the user, and it is the add-on that build-tests the shared change
+
 ## 2.44.0 (2026-08-23)
 
 - Fix: Use `portainer/agent:alpine-sts` to match the STS release channel configured in `updater.json`

portainer_agent/config.yaml

@@ -41,4 +41,4 @@ schema:
 slug: portainer_agent
 udev: true
 url: https://github.com/alexbelgium/hassio-addons
-version: "2.44.0"
+version: "2.44.0.1"