home.sessionVariables has no effect when using a graphical desktop environment

[sigwinch28]

At the time of writing, the contents home.sessionVariables are placed in ~/.profile.

As I use KDE Plasma, these variables never get loaded for me because:

• /etc/profile on NixOS 19.09 does not source ~/.profile
• sddm does not source ~/.profile
• Konsole and other terminal emulators start non-login interactive shells by default (and therefore do not load ~/.bash_profile or ~/.profile, but ~/.bashrc instead)

For example, if I set:

home.sessionVariables = { EDITOR = "emacs" };

I get:

[joe@mycomputer:~] $ echo $EDITOR
nano

My ~/.profile, ~/.bash_profile, and ~/.bashrc files are all managed by home-manager and their contents are as follows:

# ~/.profile
# -*- mode: sh -*-

. "/home/joe/.nix-profile/etc/profile.d/hm-session-vars.sh"

# ~/.bash_profile
# -*- mode: sh -*-

# include .profile if it exists
[[ -f ~/.profile ]] && . ~/.profile

# include .bashrc if it exists
[[ -f ~/.bashrc ]] && . ~/.bashrc

# ~/.bashrc
# -*- mode: sh -*-

# Commands that should be applied only for interactive shells.
if [[ $- == *i* ]]; then
  HISTFILE="$HOME/.bash_history"
HISTFILESIZE=100000
HISTSIZE=10000

  shopt -s histappend
shopt -s checkwinsize
shopt -s extglob
shopt -s globstar
shopt -s checkjobs

  
fi

To make matters worse, it seems that NixOS doesn't make an authoritative decision about whether ~/.profile (or actually, whether any other file) will be reliably sourced at login when using a graphical environment (NixOS/nixpkgs#5200)

If I log in via the console or via SSH however, this does count as a bash login shell and my environment variables are set correctly.

For now my current workaround is to put the following in my system's /etc/nixos/configuration.nix which applies a workaround at the system level:

environment.loginShellInit = ''
	if [ -e $HOME/.profile ]
	then
		. $HOME/.profile
	fi
'';

but I could just as easily put the following in my home.nix:

home.file.".xprofile".text = ''
	if [ -e $HOME/.profile ]
	then
		. $HOME/.profile
	fi
'';

I also think I could get around this by putting xsession.enable = true; in my home.nix which would add the necessary if [ -e $HOME/.profile ] ... code to my ~/.xprofile.

Any comments or suggested solutions to this quirk between home-manager and NixOS, or anything in the documentation I have missed?

[tfc]

I have the same problem.

Adding the

home.file.".xprofile".text = ''
	if [ -e $HOME/.profile ]
	then
		. $HOME/.profile
	fi
'';

snippet to my home manager config however does not work with gnome. When i do source ~/.xprofile, that works, but simply by logging in into gnome and looking up my env in the shell, i don't see this was sourced.

[mammothbane]

Completely untested, but you might try systemd.user.sessionVariables instead

[roosemberth]

I'm using this to address the issue, works like a charm:

    # Source home-manager environment
    environment.extraInit = concatMapStringsSep "\n" (user: let
      homedir = config.users.users.${user}.home;
    in ''
      if [ "$(id -un)" = "${user}" ]; then
        . "${homedir}/.nix-profile/etc/profile.d/hm-session-vars.sh"
      fi
    '') ["user1" "user2"]);

[onny]

Completely untested, but you might try systemd.user.sessionVariables instead

cool this worked for me. But I have to note that I autostart my window manager Sway also with this command:

systemctl --user import-environment

[tfc]

Completely untested, but you might try systemd.user.sessionVariables instead

@mammothbane unfortunately does seem to be ignored by gnome.

I am currently setting env vars that shell also be available in gnome shells like this:

  programs.bash.bashrcExtra = ''
    SSH_AUTH_SOCK="/run/user/$UID/gnupg/S.gpg-agent.ssh"
  '';

i don't like it, but i also don't want to change anything in /etc/nixos/configuration.nix to make this work, as this would break my session vars for all the systems i have no root access to.

[Vonfry]

Could home-manager set systemd.sessionVariables with home.sessionVariables by default?

[maisiliym]

The right way to fix this is to wrap apps which need the socket, since giving an env var to an application that shoundnt use it is both wasteful and incorrect. This is why gnome stopped sourcing profile's, and is the way forward. Li's plan is to use systemd units to launch all apps. Gnome devs have been discussing this also.

[dotKuro]

I looked into the source of the zsh and bash nix expression respectivly and noticed that both of them are just sourceing the session variables incorrectly: They are sourcing them in the .zshrc/.bashrc, which only affects the actual shells. In order to have them more globally I'd suggest sourcing them in .bash_profile/.xprofile/.zsh_env respectivly.

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close 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

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, 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.

[putchar]

Hello
i am having the same issue with bash

here is my snippet

  programs.bash = {
    enable = true;
    sessionVariables = {
      VAGRANT_DEFAULT_PROVIDER="libvirt";
      TERM="xterm-256color";
      };
    };

should we depreciate this option in favor of systemd.user.sessionVariables ?

Edit:
It seems those two other options do not work either

  home.sessionVariables = {
    VAGRANT_DEFAULT_PROVIDER="libvirt";
    TERM="xterm-256color";
  };

  systemd.user.sessionVariables = {
    VAGRANT_DEFAULT_PROVIDER="libvirt";
    TERM="xterm-256color";
  };

to have something working i had to update my bash as follows

  programs.bash = {
    enable = true;
    bashrcExtra = ''
      export VAGRANT_DEFAULT_PROVIDER="libvirt";
      export TERM="xterm-256color";
    '';
    };

[berbiche]

cc @rycee

I think the variables in bash.sessionVariables are only loaded when run from an interactive shell which is why they are not loaded by your desktop environment.
Same goes for home.sessionVariables I think.

As for systemd.user.sessionVariables, this only applies to systemd services.

[rycee]

@berbiche Yeah, that's right. Except that home.sessionVariables is pretty much intended for any login session. If xsession.enable is enabled then HM will create an ~/.xprofile file containing, among other things,

. "${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh"

X login sessions should load this file and introduce the variables.

People who don't want HM to manage the X session can manually put that line in their ~/.xprofile file (replacing ${config.home.profileDirectory} by the appropriate value).

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close 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

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, 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.

[colemickens]

Any word if xsession.enable works with the GNOME Wayland session?

[berbiche]

@colemickens
Any word if xsession.enable works with the GNOME Wayland session?

AFAIK no. The Home Manager generated .xprofile file is not sourced by any Wayland display managers, including Gnome.

[colemickens]

Does it make sense to open something new for that scenario? Maybe I will later if no one protests or points me in a better direction.

[berbiche]

Does it make sense to open something new for that scenario? Maybe I will later if no one protests or points me in a better direction.

Please do :)

[kira-bruneau]

This has been fixed in NixOS with NixOS/nixpkgs#185987.

We now source ~/.profile in xsessionWrapper, but I think we'll eventually want to generalize this to load the actual login shell environment for the given $SHELL. The way we have it hard-coded right now is intended to emulate the login shell environment for sh - which is what we were partially already doing by sourcing /etc/profile.

[auroraanna]

@kira-bruneau So home.sessionVariables is supposed to work graphical sessions again? It doesn't for me…

[thall]

@auroraanna I have the same problem.
My workaround:

programs.bash.initExtra = ''
  export EDITOR="vim"
'';

[dacioromero]

I don't think this should be closed.

I use KDE Wayland, SDDM, and Zsh and my home.sessionVariables aren't sourced by either SDDM or KDE. This means programs.mangohud.enableSessionWide won't work with any program started outside of a terminal.

Following https://userbase.kde.org/Session_Environment_Variables I've added the following to my configuration:

{ config, ... }: {
  xdg.configFile."plasma-workspace/env/hm-session-vars.sh".text = ''
    . "${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh"
  '';
}

This fixes programs.mangohud.enableSessionWide

---

I'm not sure if this is a bug with KDE, SDDM, or with how NixOS packages them seeing that I've read in several places that SDDM and maybe even KDE should source files like .zprofile and .zshenv.

https://wiki.archlinux.org/title/environment_variables#Per_Wayland_session

However, SDDM sources startup scripts for login shells on Wayland sessions too.

https://github.com/sddm/sddm/blob/5d260e2328b7ed44232ed8b3368bd59194d30357/data/scripts/wayland-session#L26

zshenv is always sourced automatically.

[auroraanna]

This has been fixed in NixOS with NixOS/nixpkgs#185987.

We now source ~/.profile in xsessionWrapper, but I think we'll eventually want to generalize this to load the actual login shell environment for the given $SHELL. The way we have it hard-coded right now is intended to emulate the login shell environment for sh - which is what we were partially already doing by sourcing /etc/profile.

oh, does that only work in Xorg sessions? That would explain why it's still not working for me. I'm using Wayland.

[haizaar]

@dacioromero solution is a great step forward but still has a caveat - whatever is defined in environment.variables will override your home.sessionVariables.

Here is why:

• Plasma will load your ${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh, which will set __HM_SESS_VARS_SOURCED=1
• When you start a new bash instance, e.g. through konsole, it will load /etc/bashrc (since the bash was compiled with -DSYS_BASHRC="/etc/bashrc"), which will source /etc/profile first thing and then the rest of of /etc/bashrc
• /etc/profile loads environment generated by environment.variables. Hence, for example, if you have less enabled, it will setup LESSOPEN through environment.variables and trying to override LESSOPEN with home.sessionVariables will not work - the former will be sourced on every interactive bash opened while home.sessionVariables will be sourced only once by plasma
• Even if you source home.sessionVariables in your ~/.bashrc it will still not work since __HM_SESS_VARS_SOURCED is already set by plasma

At this stage I wouldn't put interactive shell related stuff in home.sessionVariables

[dacioromero]

SDDM was updated to 0.20.0 and is in nixos-unstable NixOS/nixpkgs#239389 and it seems to source my .zshenv so I don't need my workaround. It'll probably have the same caveat that @haizaar pointed out though.

[mrshiposha]

The following worked for me:

let homeManagerSessionVars = "/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh";
in {
    environment.extraInit = "[[ -f ${homeManagerSessionVars} ]] && source ${homeManagerSessionVars}";
}

[hpfr]

#1011 (comment):

The right way to fix this is to wrap apps which need the socket, since giving an env var to an application that shoundnt use it is both wasteful and incorrect. This is why gnome stopped sourcing profile's, and is the way forward. Li's plan is to use systemd units to launch all apps. Gnome devs have been discussing this also.

GNOME Wayland actually hasn’t stopped sourcing the login shell environment. I can’t speak for other environments, but home.sessionVariables should already work on GNOME Wayland. See my explanation in NixOS/nixpkgs#187620 (comment).

#1011 (comment):

This has been fixed in NixOS with NixOS/nixpkgs#185987.

We now source ~/.profile in xsessionWrapper, but I think we'll eventually want to generalize this to load the actual login shell environment for the given $SHELL. The way we have it hard-coded right now is intended to emulate the login shell environment for sh - which is what we were partially already doing by sourcing /etc/profile.

Indeed, this means home.sessionVariables probably only works for the X11 users with programs.bash.enable. For anyone wanting to improve the situation for X11 or their Wayland desktop environment, see my explanation in NixOS/nixpkgs#187620 (comment) of how gnome-session loads the login environment for $SHELL. Presumably a similar wrapper can be made for KDE Wayland or Sway or whatever.