+++ 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 ---
This issue still affects current Fedora 26 ("rawhide") including package gnome-session-3.23.2-2.fc26.