Support exporting variables into an starting environment #782

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

included is a refactor of rc-update also

src/librc/librc-misc.c

src/rc-update/rc-update.c

src/librc/librc-misc.c

src/rc-update/rc-update.c

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

src/librc/librc-misc.c

man/rc-update.8

src/value/value.c

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

src/librc/librc-misc.c

+	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?

src/librc/librc-misc.c

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

src/openrc-run/openrc-run.c

+		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.

navi-desu · 2025-10-05T04:45:40Z

new version.

i'm unsure about the librc api, but seems okay enough?

i've also for now added a new binary, rc-env, i still prefer rc-update env, and will try again to do that instead -- it's just a pain because of how the opt parsing and help text is structured

pam_openrc now imports the variables of services added to 'boot' to the pam environment

swagtoy

Looks good! Just some comments :-)

src/librc/librc-misc.c

src/librc/librc.c

swagtoy · 2025-10-05T05:20:36Z

src/librc/librc.c

+		if (!do_getfileat(dirfd(envdir), d->d_name, &value, &size))
+			continue;
+
+		xasprintf(&envlist[i++], "%s=%s", d->d_name, value);


I'm still in favor of having a second function to retrieve these values, since it makes it easier to pretty-print or use in, say, an application that has 2 textboxes for each key/value. (otherwise you have to rely on strchr and all that). Is this still possible? :-)

swagtoy · 2025-10-05T05:23:51Z

src/openrc-run/openrc-run.c

+		return;
+
+	for (size_t i = 0; i < count; i++)
+		putenv(env[i]);


should check putenv for errors and propagate them?

putenv only ever fails on OOM, i'm unsure how it's best to handle that

Im not a fan of how librc handles errors to begin with. We can put this aside for now and address it later. But its still good to handle oom errors if possible, typically id make macros for doing that.

But this is openrc-run, so oom is tricky. Probably best to just use perror or strerror and hope for the best.

Also, ENOMEM can also be a sign of something wrong with malloc internal structures indicating a serious bug or worse corruption (but glibc malloc will usually yell regardless). They are always nice to check.

we usually abort on allocation failure, which i really dislike and would like to handle errors properly

here i'll add a eerror but otherwise attempt to proceed with the service

Also, ENOMEM can also be a sign of something wrong with malloc internal structures indicating a serious bug or worse corruption (but glibc malloc will usually yell regardless). They are always nice to check.

that is not our problem, we assume a working malloc. if malloc is broken, we are to handle it the same as out of memory

If malloc is broken then it can at least help highlight issues. Malloc could be broken because we broke it. So, it's good to check it just incase. We have valgrind and asan but if someone reports such a bug, it's easier to see the error instead of a mysterious "malloc: blah blah broken arena"in who knows who where

It is entirely up to you though :-)

how would we have broken malloc? what scenario would that come up, and what "help" would we even give other than "error: ENOMEM"?

if you mean we go out of bounds and corrupt some malloc data, that's not on the field of "helping highlight broken malloc", that is "we did out of bound writes and that's bad™"

I mean the latter. Course it's bad, but the earlier it's caught the easier it can be smelt out. I agree through ENOMEM is not helpful for that in particular

For now you can leave it alone

If internal malloc data structures are corrupted, the implementation is free to abort or not return an error. We hope that useful implementations would abort.

I think it's unlikely that they'll return ENOMEM in such a case: it seems unlikely that an implementation could reliably detect corruption but wouldn't then abort on it.

It's hard to detect corruption. Libcurl just returns a memory error. But this is an application, so abort is fine, Sam put it best

Glibc Malloc will abort anyway if something is effed up (i recall)

src/pam_openrc/pam_openrc.c

librc api to interact with the script environemnt. 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 uses an "envdir", $RC_SVCDIR/environment is the root, and each directory inside is an envdir for the respectively named service, and 'rc' is a special directory for all services (global environment) each envdir contains files, whose names are the variables name, and contents the value to be exported

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

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

src/librc/librc-misc.c Outdated Show resolved Hide resolved

src/librc/librc-misc.c Outdated Show resolved Hide resolved

src/rc-update/rc-update.c Outdated Show resolved Hide resolved

N-R-K suggested changes Mar 7, 2025

View reviewed changes

src/rc-update/rc-update.c Show resolved Hide resolved

src/rc-update/rc-update.c Outdated Show resolved Hide resolved

src/librc/librc-misc.c Outdated Show resolved Hide resolved

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

src/rc-update/rc-update.c Show resolved Hide resolved

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

src/librc/librc-misc.c Outdated Show resolved Hide resolved

src/librc/librc-misc.c Outdated Show resolved Hide resolved

man/rc-update.8 Outdated Show resolved Hide resolved

src/value/value.c Outdated Show resolved Hide resolved

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 from 47f797f to c014c02 Compare October 5, 2025 04:40

swagtoy suggested changes Oct 5, 2025

View reviewed changes

src/pam_openrc/pam_openrc.c Outdated Show resolved Hide resolved

navi-desu force-pushed the rc-update-env branch from c014c02 to c7fd7b9 Compare October 5, 2025 20:00

navi-desu added 3 commits October 16, 2025 18:04

librc: add rc_getfileat

ac28f2c

librc: clear service envdir on stop

cb4b646

navi-desu force-pushed the rc-update-env branch 3 times, most recently from 4e4a3e0 to ec43354 Compare October 16, 2025 16:45

navi-desu added 3 commits October 16, 2025 20:02

value: add service_export helper

3091bee

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

openrc-run: import variables from dependent services

4200167

rc-env: add new binary

816eebc

navi-desu force-pushed the rc-update-env branch 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

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

Support exporting variables into an starting environment #782

Are you sure you want to change the base?

Support exporting variables into an starting environment #782

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

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!

navi-desu commented Oct 5, 2025

Uh oh!

swagtoy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swagtoy Oct 5, 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!

Choose a reason for hiding this comment

Uh oh!

swagtoy Oct 5, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

swagtoy Oct 5, 2025 •

edited

Loading

swagtoy Oct 5, 2025 •

edited

Loading

swagtoy Oct 5, 2025 •

edited

Loading