Bug 1416531

+++ This bug was initially created as a clone of Bug #1149905 +++

Description of problem:
environment differs too much between xsession and wayland-session

Version-Release number of selected component (if applicable):
F21 Alpha, gnome-session, gnome-terminal, gnome-shell 3.14.0

How reproducible:
always

Steps to Reproduce:
1. log in from GDM
2. open gnome-terminal
3. run `$ env`

Actual results:
Too many environment variables differ between wayland-session and xsession. 
Missing under wayland:
HOSTNAME, HISTSIZE, SSH_AUTH_SOCK, MAIL, HISTCONTROL,
(additionally missing: QT_IM_MODULE, XMODIFIERS, but they might be X/Wayland-related)
PATH is present in wayland, but missing ~/.local/bin and ~/bin.

Expected results:
Everything not related to X/Wayland should stay exactly the same for both xsession and wayland-session

Additional info:


This is the diff:

$ diff env-gnome-wayland.log env-xserver-gnome.log 
1,3c1,4
< XDG_VTNR=2
< XDG_SESSION_ID=3
< WAYLAND_DISPLAY=wayland-0
---
> XDG_VTNR=1
> XDG_SESSION_ID=23
> HOSTNAME=chstpc-2
> GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
7a9
> HISTSIZE=1000
9c11
< WINDOWID=31457287
---
> WINDOWID=37748743
13a16
> SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
15,17c18,22
< SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/3081,unix/unix:/tmp/.ICE-unix/3081
< PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
< DESKTOP_SESSION=gnome-wayland
---
> SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/29000,unix/unix:/tmp/.ICE-unix/29000
> PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/christian/.local/bin:/home/christian/bin
> MAIL=/var/spool/mail/christian
> DESKTOP_SESSION=gnome
> QT_IM_MODULE=ibus
18a24
> XMODIFIERS=@im=ibus
22c28
< GDMSESSION=gnome-wayland
---
> GDMSESSION=gnome
24c30
< SHLVL=1
---
> HISTCONTROL=ignoredups
26a33
> SHLVL=2
27a35
> XDG_SESSION_DESKTOP=gnome
29,30c37
< XDG_SESSION_DESKTOP=gnome-wayland
< DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-sxzA4wPn0F,guid=6e9edf7cd24da893dc7ff3ee54330131
---
> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-41xhxDHvk9,guid=fb9365cf53a86fb60b3b039d5432fe59
32,33c39
< WINDOWPATH=1:1
< DISPLAY=:1
---
> WINDOWPATH=1:1:1:1:1:1:1:1:1:1:1:1:1
34a41
> DISPLAY=:0
35a43
> XAUTHORITY=/run/gdm/auth-for-christian-HBTLf3/database

--- Additional comment from Christian Stadelmann on 2014-10-06 18:22:38 EDT ---

It seems like /etc/profile is not run on login.

--- Additional comment from Christian Stadelmann on 2014-10-17 05:06:43 EDT ---

There are similar bugs reported upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=736660
https://bugzilla.gnome.org/show_bug.cgi?id=738336

--- Additional comment from Martin Meyer on 2015-01-02 09:34:45 EST ---

I also filed a bug against gnome-terminal[1], thinking this was an issue a problem with not being considered a login shell consistently between the sessions. Since the "GNOME on Wayland" session entry simply executes `gnome-session --session=gnome-wayland`, this means we skip all the xinitrc stuff that goes on with X sessions starting.

This can probably be fixed either by making gnome-session aware of the startup procedure, or by making Wayland have its own init of procedure similar to X's. I think the latter is probably a better idea, so that other desktop environments don't also have to implement this same logic.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=741874

--- Additional comment from Christian Stadelmann on 2015-04-09 11:20:08 EDT ---

Still present on F22 alpha. Note that this may trigger many more problems when applications rely on environment variables.

--- Additional comment from Christian Stadelmann on 2015-11-14 06:40:25 EST ---

Still partially present on F23. Most importantly HOSTNAME is missing which breaks gdb attaching to valgrind using vgdb as described in http://valgrind.10908.n7.nabble.com/vgdb-gdbserver-FIFO-name-mismatch-td39607.html

PATH, XMODIFIERS and SSH_AUTH_SOCK have been fixed.

HOSTNAME, HISTSIZE, HISTCONTROL, QT_IM_MODULE, MAIL, GPG_AGENT_INFO: don't exist on wayland sessions

--- Additional comment from Christian Stadelmann on 2015-11-25 07:24:34 EST ---

Specifying environment in ~/.bashrc won't work on Gnome+Wayland sessions, it is not being read/run before starting wayland applications.

Users might e.g. add local folders to PATH, LD_LIBRARY_PATH, etc. or set GDK_BACKEND=wayland or GDK_BACKEND=x11. Adding those to ~/.bashrc won't work for applications running in a gnome+Wayland session. Running them from XWayland doesn't change that. This only works fine in a true gnome+X11 session.

--- Additional comment from Mantas M. (grawity) on 2016-03-07 01:03:31 EST ---

(In reply to Christian Stadelmann from comment #5)
> Still partially present on F23. Most importantly HOSTNAME is missing which
> breaks gdb attaching to valgrind using vgdb as described in
> http://valgrind.10908.n7.nabble.com/vgdb-gdbserver-FIFO-name-mismatch-
> td39607.html
> 
> PATH, XMODIFIERS and SSH_AUTH_SOCK have been fixed.
> 
> HOSTNAME, HISTSIZE, HISTCONTROL, QT_IM_MODULE, MAIL, GPG_AGENT_INFO: don't
> exist on wayland sessions

HOSTNAME: not sure why this would exist?

HISTSIZE, HISTCONTROL: are shell-specific and don't need to be environment variables, can be just set within .bashrc

MAIL: can (should?) be set by pam_mail

GPG_AGENT_INFO: gnupg 2.1 doesn't use it anymore

--- Additional comment from Christian Stadelmann on 2016-03-07 05:04:25 EST ---

(In reply to Mantas M. (grawity) from comment #7)
> HOSTNAME: not sure why this would exist?

See comment #5: attaching gdb to valgrind breaks without specifying HOSTNAME. This could of course also be fixed in valgrind/gdb, no reason to ship unnecessary environment variables when one could just read /etc/hostname.

--- Additional comment from Mantas M. (grawity) on 2016-03-07 05:59:23 EST ---

(In reply to Christian Stadelmann from comment #8)
> (In reply to Mantas M. (grawity) from comment #7)
> > HOSTNAME: not sure why this would exist?
> 
> See comment #5: attaching gdb to valgrind breaks without specifying
> HOSTNAME. This could of course also be fixed in valgrind/gdb, no reason to
> ship unnecessary environment variables when one could just read
> /etc/hostname.

Yes, exactly – programs should use gethostname(3) or at least uname(3) to get the current system's hostname, unless it needs to be overridden for some reason. (Note that the *current* system hostname might be different from what's in /etc/hostname, so the latter is not a good source.)

--- Additional comment from Christian Stadelmann on 2016-03-07 10:55:22 EST ---

(In reply to Mantas M. (grawity) from comment #9)
> (In reply to Christian Stadelmann from comment #8)
> > (In reply to Mantas M. (grawity) from comment #7)
> > > HOSTNAME: not sure why this would exist?
> > 
> > See comment #5: attaching gdb to valgrind breaks without specifying
> > HOSTNAME. This could of course also be fixed in valgrind/gdb, no reason to
> > ship unnecessary environment variables when one could just read
> > /etc/hostname.
> 
> Yes, exactly – programs should use gethostname(3) or at least uname(3) to
> get the current system's hostname, unless it needs to be overridden for some
> reason. (Note that the *current* system hostname might be different from
> what's in /etc/hostname, so the latter is not a good source.)

I tried to reproduce this issue in gdb/valgrind to report it but it has gone already.

--- Additional comment from Paul Eggert on 2016-09-08 11:46:56 EDT ---

I independently ran into this problem, and would like to emphasize that this is a serious shortcoming of Wayland on Fedora 24. I need to have a way to set environment variables all throughout my desktop session; not just standard environment variables like 'PATH' and 'TZ', but also my own variables (like 'j') that I use all the time for my own purposes. These are not systemwide variables; they're just personal settings. I use this capability all the time in my software development environment.

I have worked around the problem by not using Wayland for now.

--- Additional comment from Christian Stadelmann on 2016-09-08 12:34:18 EDT ---

(In reply to Paul Eggert from comment #11)
> I independently ran into this problem, and would like to emphasize that this
> is a serious shortcoming of Wayland on Fedora 24. I need to have a way to
> set environment variables all throughout my desktop session; not just
> standard environment variables like 'PATH' and 'TZ', but also my own
> variables (like 'j') that I use all the time for my own purposes. These are
> not systemwide variables; they're just personal settings. I use this
> capability all the time in my software development environment.
> 
> I have worked around the problem by not using Wayland for now.

Please have a look at https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#DefaultEnvironment= , you can put your ENV settings into ~/.config/systemd/user.conf

See also: https://wiki.archlinux.org/index.php/Systemd/User#Environment_variables

@Someone with wiki write access: This information might be useful to be documented somewhere unless fixed until F25 is released. With a powerful tool like systemd to the hands I don't think there is any need for having ~/.bashrc and others run at login.

--- Additional comment from Paul Eggert on 2016-09-08 18:45:45 EDT ---

(In reply to Christian Stadelmann from comment #12)

> https://www.freedesktop.org/software/systemd/man/systemd-system.conf.
> html#DefaultEnvironment= , you can put your ENV settings into
> ~/.config/systemd/user.conf

Thanks, but unfortunately that does not work for me. I created a file .config/systemd/user.conf with the contents:

[Manager]
DefaultEnvironment=j=junk k="e f"

and logged out and logged back in again. The environment variables j and k were not set.

I see that others are reporting this problem in Arch Linux, with no solution known:

https://bbs.archlinux.org/viewtopic.php?id=208650

PS. Is there any way for a user to debug problems with a bad user.conf file? I don't see any diagnostics or log file.

--- Additional comment from Roger Odle on 2016-09-10 10:19:58 EDT ---

Why wouldn't putting your variables into .bash_profile work? .bash_rc can cause recursion problems in that it gets processed every time a shell script is executed but .bash_profile only gets processed at logon.

--- Additional comment from Paul Eggert on 2016-09-10 15:21:23 EDT ---

(In reply to Roger Odle from comment #14)
> Why wouldn't putting your variables into .bash_profile work?

Because Wayland-based logins don't use use Bash as a login shell and therefore ignore .bash_profile. As far as I know they do not use Bash at all, unless the user decides to run Bash by running a terminal or something.

I need environment variable settings to be visible to every process in my Wayland session. For example, if I start up Emacs from the desktop, that Emacs should see the environment variable setting even though Bash was never run.

The Wayland design purposely bypasses .bash_profile, I assume because it wants to protect users from the complexity of programming and scripts. This means Wayland needs to provides the essential feature of environment-setting. Currently it lacks this feature under Fedora 24, which is a show-stopper.

--- Additional comment from Ray Strode [halfline] on 2016-09-12 10:15:11 EDT ---

> > https://www.freedesktop.org/software/systemd/man/systemd-system.conf.
> > html#DefaultEnvironment= , you can put your ENV settings into
> > ~/.config/systemd/user.conf
> 
> Thanks, but unfortunately that does not work for me. I created a file
> .config/systemd/user.conf with the contents:
> 
> [Manager]
> DefaultEnvironment=j=junk k="e f"
> 
> and logged out and logged back in again. The environment variables j and k
> were not set.

The reason this doesn't work, is you need a GDM with this commit:

https://git.gnome.org/browse/gdm/commit/?id=448134d3cdbc54e5359ea33d387993b0defdaefa

but that's only in F25.  Without that commit, only things started by systemd --user (so dbus activated things, and service files written in /lib/systemd/user) would pick up you configuration.  Try /etc/environment for now, but we're working on a better solution in upstream systemd here:

https://github.com/systemd/systemd/pull/3904

--- Additional comment from srakitnican on 2016-10-02 02:16:25 EDT ---

Setting http_proxy environment variable in /etc/profile.d works for Firefox in X session, but not for Wayland session. But variable gets set in gnome-terminal. Firefox is set to use system settings for proxy.

Xwayland does not read /etc/profile.d?

--- Additional comment from Andy Wang on 2016-11-11 14:14:25 EST ---

So with fedora 25 on the cusp of being released, what is the appropriate soluton here?  I see comment 16 saying to use /etc/environment but that seems a little unfortunate.  A regular user shouldn't be using /etc/environment to configure their own environment.

--- Additional comment from Glen Turner on 2016-11-17 19:41:20 EST ---

Note that .~/bash_profile can do more than set environment variables. Perhaps more worrying is ~/.bash_logout, which commonly runs "sudo -k".

--- Additional comment from J. Haas on 2016-11-21 03:47:22 EST ---

So according to comment 5 PATH is fixed, but I'm still missing ~/bin/ from path from gnome-terminal inside a F25 Workstation wayland session.

--- Additional comment from Emmanuel Touzery on 2016-11-25 09:54:08 EST ---

so ~/.config/systemd/user.conf seems interesting on fedora 25+, but I can't use it to add for instance ~/bin to $PATH, because I would be overwriting the system PATH, right?

I'd like
export PATH=$PATH:~/bin

--- Additional comment from Christian Stadelmann on 2016-11-25 10:21:31 EST ---

(In reply to Emmanuel Touzery from comment #21)
> so ~/.config/systemd/user.conf seems interesting on fedora 25+, but I can't
> use it to add for instance ~/bin to $PATH, because I would be overwriting
> the system PATH, right?
> 
> I'd like
> export PATH=$PATH:~/bin

According to man systemd.exec this is not possible.

--- Additional comment from Emmanuel Touzery on 2016-11-25 15:02:42 EST ---

Yes so ~/.config/systemd/user.conf does not fully replace the previous mechanism which allowed the user to add custom folders to the PATH. as far as I can tell this is currently impossible with wayland :-(

--- Additional comment from D. Hugh Redelmeier on 2016-11-26 22:15:53 EST ---

This is clearly a bug in the default Fedora 25 configuration.

Simple observation:

With gnome terminal session, ~/bin is not in $PATH
With a console it is included.

The lack of ~/bin in PATH is an undocumented change.  Not good.

--- Additional comment from Debarshi Ray on 2016-11-29 10:31:50 EST ---



--- Additional comment from Erik Bartoš on 2016-12-01 03:45:24 EST ---

I can confirm on Fedora 25 Workstation.

$HOME/bin accessible only from $bash command line, not through Alt+F2 in Wayland.

--- Additional comment from Kamil Páral on 2016-12-01 06:26:20 EST ---

We know it doesn't work, we don't need any more confirmations. You can subscribe to this ticket even without adding a comment, just add yourself to the CC list. Thank you.

--- Additional comment from Jens Petersen on 2016-12-04 22:50:38 EST ---

Any good reason not to patch Fedora (or upstream) to use a login shell again when starting gnome-session until a better solution is available (in 3.24 say)?

--- Additional comment from Jens Petersen on 2016-12-05 00:10:31 EST ---

~/.config/systemd/user.conf does not seem to support setting DefaultEnvironment in F25 at least.

--- Additional comment from Debarshi Ray on 2016-12-05 09:13:05 EST ---



--- Additional comment from Nadav Har'El on 2016-12-07 08:11:50 EST ---

Jen, no, no good reason, except apparently the upstream only cares about Gnome and not the shell and its non-gnome utilities, so Fedora should fix it directly.

I outlined a possible easy solution in the upstream bug tracker: in the script /usr/bin/gnome-session, where we currently have the line:

exec /usr/libexec/gnome-session-binary "$@"

we could replace replace it by something like:

exec -l $SHELL -c "exec /usr/libexec/gnome-session-binary $*"

Or more safely (checking $SHELL for sanity),

$SHELL -c "exec /usr/bin/true" && exec -l $SHELL -c exec "/usr/libexec/gnome-session-binary $*" || exec /usr/libexec/gnome-session-binary "$@"

(I'm not sure what this "$@" was supposed to contain so I'm not exactly sure about that part).

--- Additional comment from Berend De Schouwer on 2016-12-07 08:52:06 EST ---

(In reply to Nadav Har'El from comment #31)
> I outlined a possible easy solution in the upstream bug tracker: in the
> script /usr/bin/gnome-session, where we currently have the line:
> 
> exec /usr/libexec/gnome-session-binary "$@"
> 
> we could replace replace it by something like:
> 
> exec -l $SHELL -c "exec /usr/libexec/gnome-session-binary $*"
> 
> Or more safely (checking $SHELL for sanity),
> 
> $SHELL -c "exec /usr/bin/true" && exec -l $SHELL -c exec
> "/usr/libexec/gnome-session-binary $*" || exec
> /usr/libexec/gnome-session-binary "$@"
> 
> (I'm not sure what this "$@" was supposed to contain so I'm not exactly sure
> about that part).

"$@" is $* with spaces preserved.

If your script is called with 'apple "pear fruit"', and you call another script or binary with $*, that binary gets three arguments: 'apple', 'pear' and 'fruit'.

If your script calls that binary with "$@", it gets two arguments: 'apple' and 'pear fruit'.

--- Additional comment from Fedora Update System on 2017-01-05 16:32:33 EST ---

gnome-session-3.22.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-44bc42c388

--- Additional comment from Fedora Update System on 2017-01-06 18:20:22 EST ---

gnome-session-3.22.2-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-44bc42c388

--- Additional comment from Richard Schwarting on 2017-01-06 21:15:19 EST ---

Tried gnome-session-3.22.2-2.fc25 with the packages from Koji (--enablerepo=updates-testing wasn't showing -2.fc25 for me).  Afterwards, ~/.bash_profile still isn't sourced, and now if I do gnome-session --version, I get

$ LANG=C gnome-session --version
/usr/bin/gnome-session: line 17: [: missing `]'
/usr/bin/gnome-session: line 18: : command not found
/usr/bin/gnome-session: line 19: -n: command not found

--- Additional comment from srakitnican on 2017-01-07 01:36:47 EST ---

(In reply to Richard Schwarting from comment #35)
> Tried gnome-session-3.22.2-2.fc25 with the packages from Koji
> (--enablerepo=updates-testing wasn't showing -2.fc25 for me).  Afterwards,
> ~/.bash_profile still isn't sourced, and now if I do gnome-session
> --version, I get
> 
> $ LANG=C gnome-session --version
> /usr/bin/gnome-session: line 17: [: missing `]'
> /usr/bin/gnome-session: line 18: : command not found
> /usr/bin/gnome-session: line 19: -n: command not found

There is a missing "\" at the end of the "if" line split. Should be:

if [ "$XDG_SESSION_TYPE" = "wayland" -a \
     "$XDG_SESSION_CLASS" != "greeter" -a \
     -n "$SHELL" ]; then

--- Additional comment from Christian Klomp on 2017-01-10 15:16:43 EST ---

Using the stable gnome-session release on F25: when gnome autologin is enabled (which defaults to Wayland) variables from /etc/environment do not end up in the session. I need to log out and log back in, then they are respected.

--- Additional comment from Christian Klomp on 2017-01-12 07:35:04 EST ---

The /etc/environment with gdm autologin problem doesn't seem to be related to Wayland since the same thing happens when Wayland is disabled.
Opened a separate bug for it: https://bugzilla.redhat.com/show_bug.cgi?id=1412608

--- Additional comment from Fedora Update System on 2017-01-16 10:19:28 EST ---

gnome-session-3.22.2-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-84b0233854

--- Additional comment from Fedora Update System on 2017-01-16 17:24:38 EST ---

gnome-session-3.22.2-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-84b0233854

--- Additional comment from David H. Gutteridge on 2017-01-16 21:58:15 EST ---

gnome-session-3.22.2-3.fc25 addresses the issue for me. Thanks for this. (Previously, I had to define certain debugging environment variables in the systemd user@.service file, which was not optimal.)

--- Additional comment from Kamil Páral on 2017-01-17 03:13:30 EST ---

(In reply to Fedora Update System from comment #40)
> gnome-session-3.22.2-3.fc25 has been pushed to the Fedora 25 testing

Works for me.

--- Additional comment from Fedora Update System on 2017-01-17 14:53:07 EST ---

gnome-session-3.22.2-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

--- Additional comment from "FeRD" (Frank Dana) on 2017-01-18 07:54:21 EST ---


I updated https://fedoraproject.org/wiki/Common_F25_bugs#gnome-login-shell to indicate that the fix has been released to stable.

--- Additional comment from Joachim Frieben on 2017-01-18 14:04:37 EST ---