Set environment variables for gnome on wayland and bash on virtual terminals (or ssh)

Gnome 3.22 uses wayland by default. Gnome on wayland does not read ~/.profile (or ~/.bash_profile or /etc/profile). See https://bugzilla.gnome.org/show_bug.cgi?id=736660.

I have my initialization files set up as following:

• .bash_profile does nothing but source .profile and .bashrc
• .profile only sets environment variables like PATH and LC_MESSAGES
• .bashrc sets some bash specific settings and aliases and environment variables for applications like less and grep.

The effect (before wayland) was following:

• when I login graphically .profile was read and environment variables like PATH and LC_MESSAGES were set. when I open bash inside a terminal emulator then .bashrc was read.
• when I login under a virtual terminal then .bash_profile was read which in turn reads .profile and .bashrc.
• when I login using ssh then behaviour is similar to virtual terminal.

In all cases .profile and .bashrc were read and my environment was set up.

So now gnome 3.22 uses wayland and wayland does not read .profile. How can I set up my initialization files so that I again have the effects as described above?

Note that I do not insist that certain files (like .profile) are read. What I want is to have my environment set up in a sensible way. That means I want to keep bash specific settings to the bash initialization files and other settings to other initialization files. Also I would like to not copy the settings over different files.

I use arch linux. Answers for all distributions are welcome. When suggesting a workaround please also describe the side effects and the advantages and disadvantages.

update november 2017: as far as i understand the gnome developers have acknowledged that people expect their login shell config files (.profile and .bash_profile in case of bash) are sourced after login. regardless of text or graphical login. so my use case outlined above works again.

still the gnome developers want to move away from starting a login shell. it seems that the direction they are going is to use environmentd from systemd:

https://in.waw.pl/~zbyszek/blog/environmentd.html

it seems that it will take a while until all login methods are adapted to environmentd.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Systemd version 233 (March 2017) added support for setting environment variables in ~/.config/environment.d/*.conf. See the environment.d man page and the discussion that led to the feature on this preliminary PR and this final one.

Method 2

This is the workaround that I use for the exact same problem:

Step 1

Create a script that sources ~/.profile and make that script executable. Let’s call it /path/to/startup.sh. It could look something like this:

#!/bin/bash
. ~/.profile

Step 2

Create a desktop application to run the script. To do this you need to create a .desktop file and place it in ~/.local/share/applications (or /usr/share/applications if you want it to work for all users). Let’s call it ~/.local/share/applications/startup.desktop. It could look something like this:

[Desktop Entry]
Name=Startup
Keywords=startup
Exec=/path/to/startup.sh
Type=Application

For more information on .desktop files see here.

Step 3

Log out. Log back in. You should now be able to search for your application in the applications menu.

Step 4

Set this application as a startup application. To do this I used the Gnome Tweak Tool and added my application to the list in the Startup Applications tab.

And that’s it! You should now have your old functionality back whenever you log in. It also preserves the file structure intact, so, when the bug in Wayland gets fixed, all you need to do it remove the application from the startup application list, delete the two files and everything is back to normal.

Later edit

As @Guss points out in the comments, this workaround will not export environment variables because startup.sh is run in its own shell. So we need another workaround for those.

Reading from the GNOME documentation you can see that there are a few alternatives. The only one that I could get to work was to create a file in /usr/share/gdm/env.d/ and, in that file, place the variables to be exported. However, this means that the variables will be exported for all users so what I ended up doing is this:

Let’s say we have two users, john and sally. For each of them create a file in /usr/share/gdm/env.d/, let’s call them startup_john.env and startup_sally.env. In those files place the environment variables to be exported when they start a new GNOME session.

$ cat startup_john.env
VAR=1
$ cat startup_sally.env
VAR=2

At this point the problem is that both files will be loaded for both users. In order solve this we set the permission on each file such that only its owner may read its contents.

$ ls -l startup_john.env
-rw-r-----. 1 john john 4 Dec 27 15:17 startup_john.env
$ ls -l startup_sally.env
-rw-r-----. 1 sally sally 4 Dec 27 15:16 startup_sally.env

Not the most elegant solution, I agree, but, as far as I have tested, it seems to get the job done.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0