Use systemd-environmentd or pam to override xdg-paths

[Thaodan]

You can also use these override the xdg variables as the service or pam runs before the user session is active.

[Thaodan]

Oh I see you are already using, is there a reason that editing the service is still needed?

[Thaodan]

I noticed that in some places you set vars manually or parse environment.d you can just call:
export $(run-parts /usr/lib/systemd/user-environment-generators | xargs)

Instead.

[ayekat]

Hi, thanks for your interest in this repo! :-)

The PAM approach no longer works due to pam_env.so having deprecated the user_readenv option (discussions in linux-pam#7), hence my switch to something that does not involve PAM in cea0a05.

However, in that commit I also noticed that merely using environment.d does not work entirely as intended, because the systemd user instance itself does not adopt the variables. So while all user units adopt the new envvars, systemd itself reads its units from ~/.config/systemd, replaces %E in unit files by ~/.config, etc.

The way I see it, there is currently no way of solving the bootstrapping issue purely on a user level, hence my workaround solution of extending my user's user@.service where possible, or simply give up and let systemd create a mess in my homedir.

---

On using the provided environment generators rather than parsing the variable files manually, that does seem more elegant indeed, thanks for the suggestion! :-)
I'll see if I can implement this sometime soon.

[Thaodan]

If you set the variables early enough than it picks them up. It is a chicken and egg issue, in the end I also modified the user unit. For sddm to pick my zsh config I also needed to set zdotdir earlier than environment.d is parsed. If I would use bash as a login shell I would at least need .profile as they are to ignorant.

[ayekat]

Improved environment generation in 5460772 (no more manual parsing). Not doing it with run-parts, because I cannot assume that to be universally available.

---

If you set the variables early enough than it picks them up.

Unfortunately, the "early enough" is "before the user unit starts", so it's either extending the user unit itself or setting the variables at PAM level (e.g. /etc/environment, which is ugly).

Ideally, user@.service would allow the user to provide an environment file somewhere in it's home (I'd probably go with ~/.environment) that it sources with EnvironmentFile=-…, but I could not find a way to determine the user name from within the unit file. 🙁

[Thaodan]

Improved environment generation in 5460772 (no more manual parsing). Not doing it with run-parts, because I cannot assume that to be universally available.

I used xargs -0, didn't use eval but that seems to work too.

If you set the variables early enough than it picks them up.

Unfortunately, the "early enough" is "before the user unit starts", so it's either extending the user unit itself or setting the variables at PAM level (e.g. /etc/environment, which is ugly).

Ideally, user@.service would allow the user to provide an environment file somewhere in it's home (I'd probably go with ~/.environment) that it sources with EnvironmentFile=-…, but I could not find a way to determine the user name from within the unit file. slightly_frowning_face

Yeah that is what I couldn't avoid too. But anything outside of /etc is chicken and e.g. issue.

[ayekat]

Turned out my solution was a bit bugged (only found out later upon restarting my session), so had to adapt the variable exporting a little more with 1e25dd7, but it now works for me.

Going to close this for now, thanks for your input!