18

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.

Improve this question

2 Answers 2

Reset to default
17

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.

Improve this answer
5
  • 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? Commented Nov 8, 2017 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. Commented Nov 8, 2017 at 20:13
  • 1
    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? Commented Nov 8, 2017 at 22:51
  • 3
    This doesn't work for me on Fedora 30 with GDM/Wayland. Commented Jun 28, 2019 at 1:24
  • 1
    The 'solution' misses a reasonable use case: if A, then set B. As one example, if XDG_SESSION_TYPE=wayland then set QT_QPA_PLATFORM=wayland. Commented Dec 11, 2019 at 4:13
5

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.

Improve this answer
4
  • 1
    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. Commented Dec 26, 2016 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. Commented Dec 27, 2016 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 Commented Dec 27, 2016 at 12:37
  • 1
    Absolutely shocking that this is still not somehow taken care of. All that just to source my .profile?!? Commented Feb 18, 2020 at 22:38

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.