bug: hm-session-vars forces variables to be only set once, forcing log-out or reboot for Gnome users

[Bujiraso]

Are you following the right branch?

• My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• I have searched the existing issues

Issue description

Within ~/nix-profile/etc/profile.d/hm-session-vars.sh are the lines:

# Only source this once.
if [ -n "$__HM_SESS_VARS_SOURCED" ]; then return; fi

Let's call this a "reload blocker". Perhaps these were intended for performance boost but they are having a tremendously faulty effect in a Gnome graphical session.

Gnome loads the user's profile and other variables while logging them in, and these variables (including the reload blocker) are loaded. This means that after the user changes hm-session-vars in their configuration, every single terminal they open has the old variables. The new variables are blocked from loading by the reload blocker.

This forces the user to log-out (expensive in time and closes all programs) or to reboot entirely in my case. The reboot may be a bug in Gnome, but the fix is simple: let's add an option to disable these lines within home-manager.

From my vantage, the tiny amount of variables being reloaded poses absolutely zero performance impact, so I would love for these to be hot-reloaded on every terminal.

Maintainer CC

No response

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.3.1-zen2-1-zen, Arch Linux, noversion, rolling`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.15.0`
 - nixpkgs: `/home/nicholas/.nix-defexpr/channels/nixpkgs`

[emilazy]

It's not just for performance but also because variables can append to others (e.g. if you have a non-empty sessionPath or manually append to MANPATH or similar in your configuration), which could lead to arbitrary amounts of duplication as environments nest.

[Bujiraso]

Sure -- that's definitely a use-case worth keeping the lines available as a toggle. I don't care which way the default goes 😉

But otherwise, it's this old meme 😆

[Bujiraso]

Actually... Quick follow-ups, this could work, too:

home.sessionVariablesOnce = {
      PATH = "$PATH:/my/dir;
      MANPATH = "$MANPATH:/man/path;
};
home.sessionVariables = { 
      CARGO_HOME = ''''${HOME}/.cargo'';
      EDITOR = "vim";
};

Results in

CARGO_HOME = ''''${HOME}/.cargo'';
EDITOR = "vim";
# Only set these once.
if [ -n "$__HM_SESS_VARS_SOURCED" ]; then return; fi
PATH = "$PATH:/my/dir;
MANPATH = "$MANPATH:/man/path;

There's myriad solutions 🎉

[emilazy]

i think having everything else update except your PATH when making changes would be even more confusing than the status quo and could lead to things breaking in unexpected ways. It would also lead to inconsistencies between graphical applications and terminals.

That said I agree that it'd be nice if this was solved, I'm just not sure how best to do that. (Honestly I think graphical sessions running shell profile scripts is probably not ideal in general. The Arch wiki claims that GDM does not do this for Wayland sessions, although apparently this might not actually be true, at least on Arch?)

[Bujiraso]

I'll agree partial refreshes and split variables aren't worth arguing further.
That being said, control over whether or not those variables get resourced is trivial to implement and seemingly necessary, based on how the user is loaded. That is, it's not actually GDM, it seems.

I'm seeing that it's the user-$UID.scope that needs to be restarted in order to get any of the variables refreshed.

$ sudo systemctl restart user-1000.scope # where my ID is 1000

Even if I'm logged out in GDM, the variables don't refresh until I run this. Running this does forcibly end the graphical user session and log me out, so it's certainly no fix for this issue.

Two take-aways:

1. Having user control of a boolean to toggle these blocker lines is still a great fix
2. A reboot isn't necessary if $ sudo systemctl user-$(id -u).scope works for you, but it is still highly destructive (i.e. logs you out, kills all programs)

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/home-manager-sessionvariables-not-persisted-after-log-out/55021/2

[stereomato]

this is still an issue!

[stevenroose]

Yeah this is still unintuitive to me. I update my conf file and the variables don't show up. Similarly programs.zsh.sessionVariables has the same behavior and it's also non-intuitive. Especially since zsh sessions get started and stopped all the time.

I think there should be a different way for the session to prevent this file from being sourced more than once. It should be the session's responsibility to not source the file twice instead of the file's respondibility to ensure it's callers don't call it twice.

This feels a bit like a method returning an error if it's called twice with the same argument saying "dude I already calculated this yesterday".

This is the second time I'm trying to trace down why my variables don't show up and bumping into this (bad short term memory).

I actually find the suggested change above quite intuitive: having a sessionVariablesOnce and a regular sessionVariables.

[stevenroose]

An attempt at implementing @Bujiraso 's suggestion: #6594