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.

up vote 5 down vote accepted

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.

  • this seems to be a very good solution. i did a quick test. it works in gnome wayland but does not work in virtual terminal. i assume it will also not work for ssh. i have read the man page but only skimmed the discussions. do you have any idea whether this will also work in virtual terminals and ssh? – lesmana Nov 8 '17 at 15:38
  • 1
    here is a nice summary of the situation: in.waw.pl/~zbyszek/blog/environmentd.html. the last paragraph says that support for virtual terminal (and ssh?) "might" come. at least if i understood that correctly. – lesmana Nov 8 '17 at 20:13
  • Oh interesting, I didn't realize that GDM had to add special support for this to make it work. Could there have been some kind of arrangement where all types of sessions are children of a single user service process, which has already parsed these env vars, and it all just works without GDM/sshd needing to know anything about it? – Jack O'Connor Nov 8 '17 at 22:51

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.

  • I haven't tested this, but it shouldn't work because the startup.sh is running in its own shell and won't export environment variables to a parent execution context. As an example, try running this code in your shell: echo "a is $a"; (export a="B"); echo "a is $a" . According to @Tudor, the output from the second echo will be a is B, which - you'll see when you run the code - is not what happens. – Guss Dec 26 '16 at 12:48
  • Hi @Guss, you are correct. I didn't notice that but, now that you've pointed it out, I found a workaround for environment variables as well. I will update my answer accordingly. – Tudor Vișan Dec 27 '16 at 9:07
  • 1
    Please do, I'd love to see what you've come up with. Also, I think you are way optimistic when you say "when the bug in in Wayland gets fixed" - this is not a bug in Wayland but in GNOME, and GNOME people don't consider this a bug - its a documented behavior: wiki.gnome.org/Initiatives/Wayland/SessionStart – Guss Dec 27 '16 at 12:37

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.