s6 environment variables

[orhid]

it appears to me that while using s6 as a supervisor, the environment variables defined either in the openrc script itself or in the corresponding conf.d file are ignored. here is a small test setup that works with supervisor=supervise-daemon but not with supervisor=s6.

#!/sbin/openrc-run
# /etc/init.d/evartest

command=/usr/bin/evartest
export VAR
supervisor=s6 # works with supervise-daemon

#!/bin/sh
# /usr/bin/evartest
echo "[$(date)] value in VAR: $VAR" >> /tmp/evartest

# /etc/conf.d/evartest
VAR=value

with supervise-daemon this puts "value" into the given file continously, while s6 puts the empty string for VAR. curiously, without the supervisor line (that is with start-stop-daemon) lines are still continously put into the file, but only one of these contains the actual value of VAR, the rest put the empty string there. when the export directive is put inside the start_pre function only the behaviour of start-stop-daemon changes — it now prints the correct value exactly once.

the s6 guide claims that The first time start() is called, OpenRC uses all the variables in the service file to build a service directory: a run script, possibly a notification-fd file, etc.. i now think that this refers only to the variables mentioned in the guide, not actually all variables. nonetheless i think this is a bug in the implementation, hence the issue, if not, maybe the guide/documentation could be updated to reflect that?

tested on alpine linux, openrc version 0.63.1 :

$ uname -a                                                                                                       
Linux hostname 6.18.35-0-lts #1-Alpine SMP PREEMPT_DYNAMIC 2026-06-09 12:34:47 x86_64 Linux                                       

$ cat /etc/os-release                                                                                            
NAME="Alpine Linux"                                                                                                                
ID=alpine                                                                                                                          
VERSION_ID=3.24.0                                                                                                                  
PRETTY_NAME="Alpine Linux v3.24"                                                                                                   
HOME_URL="https://alpinelinux.org/"                                                                                                
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"                                                             

$ openrc --version                                                                                               
openrc (OpenRC) 0.63.1

[orhid]

one way to go around that if anybody finds this useful is to put the env variables in the command like this command=env VAR=value /usr/bin/evartest but i believe this is a workaround, not the desired behaviour

[navi-desu]

the proper solution is to write the exported environment to some env-dir that s6 loads, creating such envdir in s6.sh

i think ska had a PoC for that already, not sure

[orhid]

and how would one point the openrc script to use that envdir? this should be somewhere in the documentation if this is the reccomended solution.

however the guide says that the aim is for the two supervisor backends to be interchangable. if this envdir is necessary for s6, it ought to be created from the export statements supervise-daemon already supports. or the other way around, right now the two are inconsistent

[navi-desu]

and how would one point the openrc script to use that envdir? this should be somewhere in the documentation if this is the reccomended solution.

you got it backwards, the flow should be*:

openrc script does export var
s6.sh backend loops all exported vars (w/ env or export -p)
filters out RC_* vars
the rest is used to generate the envdir
then add to the /run script a s6-envdir (i think?) call to source it

that should give it the same behaviour as supervise-daemon/start-stop-daemon