Support exporting variables into an starting environment by navi-desu · Pull Request #782 · OpenRC/openrc

navi-desu · 2025-03-04T16:54:57Z

included is a refactor of rc-update also

navi-desu · 2025-04-07T17:40:42Z

i rebased this on top of #819, so that's now a dependency of this mr

also reimplemented it with envdirs instead, makes it easier to unset variables, and we don't have to worry about escaping things at all

navi-desu · 2025-04-07T17:50:48Z

added more details in commit messages

N-R-K · 2025-04-15T09:58:43Z

+	fputs(value, envfile);
+	return fclose(envfile) == 0;


You also need to check the fputs return value. Also, shouldn't we check of envfile being NULL as well?

N-R-K · 2025-04-16T06:12:10Z

+		rc_import_variables(svc->value);
+		if (rc_service_state(svc->value) & RC_SERVICE_STOPPED) {


So service specific env are supposed to overwrite the global one?

Also should we be importing the env of a stopped service?

Also should we be importing the env of a stopped service?

no i'm just stupid and forgot the dep stop is about dependees, not dependers

So service specific env are supposed to overwrite the global one?

i dunno actually, i could see it being argued either way

i dunno actually, i could see it being argued either way

Yes, that's why I am asking. Either way we need to document it.

Or we could also provide some sort of special "const" functionality for the global env which disallows services overriding it. E.g something like: rc.override which will be sourced at the very end.

Or we can default to global env overriding service ones, and then have something like rc.preference which sets a preference but allows services to take priority.

okay, i say service-specific ones should take priority, because:

1: allows you to set something generically for all services, then override it in specific conf.d's
2: services could "choose" to allow users to override vars by doing : ${FOO:=default}
3: matches the conf.d semantics (i.e. rc.conf goes first, conf.d/$svc overrides)

N-R-K · 2025-04-16T08:29:26Z

Also, wouldn't we be able to get rid of this and simply export them into the global starting env during init?

openrc/src/shared/misc.c

Lines 67 to 71 in 6411b4b

    
           static const char *const usrenv_allowlist[] = { 
        
           	"USER", "LOGNAME", "HOME", "SHELL", "XDG_RUNTIME_DIR", 
        
           	"XDG_CONFIG_HOME", "XDG_STATE_HOME", "XDG_CACHE_HOME", 
        
           	NULL 
        
           };

Seems to be a cleaner and more deterministic approach.

navi-desu · 2025-04-16T23:24:16Z

Also, wouldn't we be able to get rid of this and simply export them into the global starting env during init?

for XDG_RUNTIME_DIR, no, since the envdir would be located in $XDG_RUNTIME_DIR/openrc/environment -- for the others we could tho it'd be a lot of "setting the same values at every invocation" and the tmpfs IO related to that, just to re-export the same vars again later?

N-R-K · 2025-04-29T23:09:09Z

for the others we could tho it'd be a lot of [...], just to re-export the same vars again later?

The point is to have a deterministic environment for starting the services instead of getting the env from the whatever calling process' env is. But that's not a blocker, can be done in later PR.

N-R-K · 2025-05-29T11:00:01Z

It'd be nice to have some user facing documentation on how this works. Maybe in service-script-guide.md.

amano-kenji · 2025-09-14T17:53:22Z

If you are trying to change openrc-run, the man page for openrc-run should change as well, or people will not know about this.

navi-desu · 2025-09-14T18:04:01Z

it's not ready yet, i'm still changing things

docs will be updated before it's merged

amano-kenji · 2025-09-27T03:35:57Z

Does this pull request export variables into a starting environment and also new login sessions? There can be multiple login sessions.

If I log in sway and then a linux virtual console, I have two login sessions. pam module should export DBUS_SESSIONS_BUS_ADDRESS to the second login session and the later ones as well as the first session that started dbus user service.

WhyNotHugo · 2025-12-11T12:21:23Z

Isn't it much simpler to export variables into an envdir from one init script and have dependant service import that envdir from their own script?

Such an approach doesn't require adding complexity to OpenRC itself.

WhyNotHugo · 2025-12-11T12:22:41Z

Perhaps I'm missing something, but if service A sets a variable for service B, reading the definition for service B provides no indication that it's receiving this environment variable from some external source.

navi-desu · 2025-12-11T14:06:01Z

Isn't it much simpler to export variables into an envdir from one init script and have dependant service import that envdir from their own script?
Such an approach doesn't require adding complexity to OpenRC itself.

not really for a few reasons:

the goal is to have it be transparent, if a variable is required to be set, like how DBUS_SESSION_BUS_ADDRESS and SSH_AUTH_SOCK are, then doing depend() { need dbus ssh-agent; } should be enough, the depend function encodes information about external factors which the service requires to work and i'd like to not split that

as well as, the service that export the variable should ideally be tied to the exported variables, and having the logic in openrc makes state cleanup easier (keeping exported variables in ram after the service is stopped would be bad, since $svc restart is expected to have a clean state

s6/runit services might encode the variables in an envdir, but openrc has the script as the source of truth, we'd use envdir as an implementation detail

pam_openrc must have access to said environment variables, variables exported by boot services will be expected to be exported in the pam session -- otherwise manual setup would be required for anyone using dbus via openrc, and that's not too great

this requirement means each service needs a standardized way of exporting said variables

currently the implementation is done via an envdir yes, but i'm changing that to an env file, reasons being: we don't need the flexibility for modification that an envdir has, each service starts with exported envs being an empty set, and adds to them as they go, and have the set cleared at the end -- so having a single file would reduce the number of syscalls and allocations necessary, while making processing easier

Perhaps I'm missing something, but if service A sets a variable for service B, reading the definition for service B provides no indication that it's receiving this environment variable from some external source.

A doesn't set variables "for B", it exports variables "required" for any service to access A, so it's more like "service B, by doing need A, it asks for all needed variables from A

WhyNotHugo · 2025-12-12T14:10:32Z

I missed the fact that the "depends" declaration triggers importing the variable, thanks for the clarification.

xz-dev · 2025-12-18T04:08:56Z

What happens when a user has multiple concurrent PAM sessions running different desktop environments (e.g., KDE on tty7 and GNOME on tty6)?

Will the exported environment variables from one session overwrite those from the other?

navi-desu · 2025-12-18T16:46:45Z

What happens when a user has multiple concurrent PAM sessions running different desktop environments (e.g., KDE on tty7 and GNOME on tty6)?

currently all pam sessions share the service directory, so they all share the same state

note that this is also the case on systemd, dinit, and pretty much all init systems

openrc does (in master) support setting different RC_SVCDIR, but running multiple parallel instances is not something tested nor that we guarantee works

it is something i want to think of properly doing eventually, but that is far off

so for now, if you're running multiple DEs at once, for now it is expected that they can share the services, e.g., pipewire, dbus, etc, (since even ignoring the environment sharing, you wouldn't be able to start two different "dbus" or "pipewire" services anyway)

swagtoy · 2025-12-18T17:14:23Z

Just for the record, starting multiple sessions like that would go haywire anyway. Especially more so if they were the _same_ environment, in which case you'd need something like userdb (which is some logind nonse), and afaik KDE has nothing for that right now, gnome only much more recently. This may also just lead to some dbus conflicts too on some components, which i know GDM had some hacks to work around in the past, not sure about KDE. Also; a lot of those environments will usually try not to step on their toes with environment variables anyway; i.e. one such case is that I needed to export DISPLAY or WAYLAND_DISPLAY (well, this works automagically for the most part, but for now...), in which case, these systems will not attempt to allocate over themselves, but at the moment of course since i have hardcoded these env variables it's impossible to do what you ask without this branch. After all, they needed to work around the conflicts on systemd too :) So at the very minimum, you might have dbus instances step on each other if the display managers don't start their own dbus, in which case, there be dragons anyway. Do at your own risk. So ideally, running multiple DE's at once is not recommend. Just keep this all in mind if you plan on actually doing that.

…

On Thu, Dec 18, 2025 at 11:47 AM navi ***@***.***> wrote: navi-desu left a comment (OpenRC/openrc#782) What happens when a user has multiple concurrent PAM sessions running different desktop environments (e.g., KDE on tty7 and GNOME on tty6)? currently all pam sessions share the service directory, so they all share the same state note that this is also the case on systemd, dinit, and pretty much all init systems openrc does (in master) support setting different RC_SVCDIR, but running multiple parallel instances is not something tested nor that we guarantee works it is something i want to think of properly doing eventually, but that is far off so for now, if you're running multiple DEs at once, for now it is expected that they can share the services, e.g., pipewire, dbus, etc, (since even ignoring the environment sharing, you wouldn't be able to start two different "dbus" or "pipewire" services anyway) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

swagtoy · 2025-12-18T17:16:02Z

Other concerns pop up too; like what if you close the lid of a laptop, press the power button, etc? This kind of thing buries a bit beyond env variables and into logind and is thus; risky behavior in the first place.

…

On Thu, Dec 18, 2025 at 12:14 PM Hyland ***@***.***> wrote: Just for the record, starting multiple sessions like that would go haywire anyway. Especially more so if they were the _same_ environment, in which case you'd need something like userdb (which is some logind nonse), and afaik KDE has nothing for that right now, gnome only much more recently. This may also just lead to some dbus conflicts too on some components, which i know GDM had some hacks to work around in the past, not sure about KDE. Also; a lot of those environments will usually try not to step on their toes with environment variables anyway; i.e. one such case is that I needed to export DISPLAY or WAYLAND_DISPLAY (well, this works automagically for the most part, but for now...), in which case, these systems will not attempt to allocate over themselves, but at the moment of course since i have hardcoded these env variables it's impossible to do what you ask without this branch. After all, they needed to work around the conflicts on systemd too :) So at the very minimum, you might have dbus instances step on each other if the display managers don't start their own dbus, in which case, there be dragons anyway. Do at your own risk. So ideally, running multiple DE's at once is not recommend. Just keep this all in mind if you plan on actually doing that. On Thu, Dec 18, 2025 at 11:47 AM navi ***@***.***> wrote: > > navi-desu left a comment (OpenRC/openrc#782) > > What happens when a user has multiple concurrent PAM sessions running different desktop environments (e.g., KDE on tty7 and GNOME on tty6)? > > currently all pam sessions share the service directory, so they all share the same state > > note that this is also the case on systemd, dinit, and pretty much all init systems > > openrc does (in master) support setting different RC_SVCDIR, but running multiple parallel instances is not something tested nor that we guarantee works > > it is something i want to think of properly doing eventually, but that is far off > > so for now, if you're running multiple DEs at once, for now it is expected that they can share the services, e.g., pipewire, dbus, etc, (since even ignoring the environment sharing, you wouldn't be able to start two different "dbus" or "pipewire" services anyway) > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.Message ID: ***@***.***>

swagtoy · 2026-02-08T23:53:40Z

heads up: In the coming week I will test this PR out and experiment with its usage as a way to propagate env variables with gnome-session-openrc. I feel like I noticed a possible design quirk (wrt local service environments) but I won't comment on it much until I really prove it's there; it has to do with how things work when services exit (and when the user logs out/logs in). i could've missed a line of code here which shows how that's handled, though.

Code overall seems fine to me.

librc api to interact with service environemnts. it allows us to set variables that would live across invocations, like, exporting *DISPLAY for gui daemons (notification, xdg-desktop), a bus address dependees should use the implementation stores the environment as a NUL-delimited list of string to a file in $RC_SVCDIR/environ, similar to /proc/$pid/environ on linux.

used to export environments set with the `export` variable in openrc-run

navi-desu · 2026-04-02T01:53:08Z

okay i'm tired of pushing this off and i'm happy with this version

any changes, we can do before 0.64

swagtoy · 2026-04-02T02:06:17Z

that's fine. thanks! I'll play with it some

navi-desu force-pushed the rc-update-env branch 2 times, most recently from 5fa5e74 to 49be101 Compare March 6, 2025 23:16

navi-desu marked this pull request as ready for review March 6, 2025 23:42

N-R-K suggested changes Mar 7, 2025

View reviewed changes

Comment thread src/librc/librc-misc.c Outdated

Comment thread src/librc/librc-misc.c Outdated

Comment thread src/rc-update/rc-update.c Outdated

N-R-K suggested changes Mar 7, 2025

View reviewed changes

Comment thread src/rc-update/rc-update.c

Comment thread src/rc-update/rc-update.c Outdated

Comment thread src/librc/librc-misc.c Outdated

navi-desu force-pushed the rc-update-env branch 3 times, most recently from f83bb7f to 5682c69 Compare March 7, 2025 09:20

N-R-K reviewed Mar 7, 2025

View reviewed changes

Comment thread src/rc-update/rc-update.c

navi-desu force-pushed the rc-update-env branch from 5682c69 to 429eaec Compare April 7, 2025 17:38

navi-desu force-pushed the rc-update-env branch from 429eaec to ca810a6 Compare April 7, 2025 17:50

navi-desu force-pushed the rc-update-env branch from ca810a6 to d90077a Compare April 15, 2025 00:54

N-R-K reviewed Apr 15, 2025

View reviewed changes

Comment thread src/librc/librc-misc.c Outdated

Comment thread src/librc/librc-misc.c Outdated

Comment thread man/rc-update.8 Outdated

Comment thread src/value/value.c Outdated

navi-desu force-pushed the rc-update-env branch from d90077a to b3f7d4c Compare April 15, 2025 09:52

N-R-K suggested changes Apr 15, 2025

View reviewed changes

navi-desu force-pushed the rc-update-env branch from b3f7d4c to 8c16022 Compare April 16, 2025 03:03

N-R-K suggested changes Apr 16, 2025

View reviewed changes

navi-desu force-pushed the rc-update-env branch from 8c16022 to abf6e0a Compare April 19, 2025 00:34

navi-desu force-pushed the rc-update-env branch from abf6e0a to 47f797f Compare May 29, 2025 08:14

navi-desu mentioned this pull request Sep 14, 2025

DBUS_SESSION_BUS_ADDRESS environment variable is not propagated to the entire session. #924

Open

navi-desu mentioned this pull request Sep 15, 2025

Make it possible to inject environment variables into openrc from outside. #925

Open

navi-desu force-pushed the rc-update-env branch 2 times, most recently from ec43354 to 816eebc Compare October 16, 2025 18:02

navi-desu mentioned this pull request Oct 18, 2025

gui-wm/sway: systemd use flag sets XDG_CURRENT_DESKTOP=sway gentoo/gentoo#44121

Open

4 tasks

navi-desu mentioned this pull request Dec 8, 2025

GNOME session OpenRC service manager support #955

Open

zyxhere mentioned this pull request Dec 18, 2025

kde-plasma/krdp: add OpenRC rc file in 6.5.4 gentoo/gentoo#45057

Closed

4 tasks

navi-desu force-pushed the rc-update-env branch 3 times, most recently from deccf1a to 1c4ca1b Compare March 28, 2026 23:58

navi-desu added 8 commits April 2, 2026 02:30

librc: clear service envdir on stop

a0e78e2

value: add service_export helper

1e50a4c

used to export environments set with the `export` variable in openrc-run

openrc-run: implement 'reexport' depend keyword.

d74f3a7

openrc-run: import variables from dependent services

0607bb7

rc-environ: new binary

cc75097

openrc-user: write startup environment for pam

3517d0b

pam_openrc: export user starting environment

667e2fb

navi-desu force-pushed the rc-update-env branch from 1c4ca1b to 667e2fb Compare April 2, 2026 00:34

navi-desu merged commit 93a1f58 into master Apr 2, 2026
10 checks passed

navi-desu deleted the rc-update-env branch April 2, 2026 01:53

		rc_import_variables(svc->value);
		if (rc_service_state(svc->value) & RC_SERVICE_STOPPED) {

Conversation

navi-desu commented Mar 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

navi-desu commented Apr 7, 2025

Uh oh!

navi-desu commented Apr 7, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

N-R-K Apr 15, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

N-R-K Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

navi-desu Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

N-R-K Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

navi-desu May 3, 2025

Choose a reason for hiding this comment

Uh oh!

N-R-K commented Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

navi-desu commented Apr 16, 2025

Uh oh!

N-R-K commented Apr 29, 2025

Uh oh!

N-R-K commented May 29, 2025

Uh oh!

amano-kenji commented Sep 14, 2025

Uh oh!

navi-desu commented Sep 14, 2025

Uh oh!

amano-kenji commented Sep 27, 2025

Uh oh!

WhyNotHugo commented Dec 11, 2025

Uh oh!

WhyNotHugo commented Dec 11, 2025

Uh oh!

navi-desu commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WhyNotHugo commented Dec 12, 2025

Uh oh!

xz-dev commented Dec 18, 2025

Uh oh!

navi-desu commented Dec 18, 2025

Uh oh!

swagtoy commented Dec 18, 2025 via email

Uh oh!

swagtoy commented Dec 18, 2025 via email

Uh oh!

swagtoy commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

navi-desu commented Apr 2, 2026

Uh oh!

Uh oh!

swagtoy commented Apr 2, 2026

Uh oh!

Reviewers

Assignees

navi-desu commented Mar 4, 2025 •

edited

Loading

N-R-K Apr 16, 2025 •

edited

Loading

N-R-K commented Apr 16, 2025 •

edited

Loading

navi-desu commented Dec 11, 2025 •

edited

Loading

swagtoy commented Feb 8, 2026 •

edited

Loading