Bug 1149905 - [Wayland][Regression] environment is incomplete, missing some entries from PATH, GPG_AGENT_INFO, SSH_AUTH_SOCK, ...
Summary: [Wayland][Regression] environment is incomplete, missing some entries from PA...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 1314964 1397573 1398269 (view as bug list)
Depends On:
Blocks: WaylandRelated WaylandByDefault 1416531
TreeView+ depends on / blocked
 
Reported: 2014-10-06 21:15 UTC by Christian Stadelmann
Modified: 2018-04-11 09:57 UTC (History)
53 users (show)

(edit)
Clone Of:
: 1416531 (view as bug list)
(edit)
Last Closed: 2017-01-17 19:53:07 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github https://github.com/systemd systemd pull 3904 None None None 2016-09-12 14:15 UTC
GNOME Bugzilla 736660 None None None Never

Description Christian Stadelmann 2014-10-06 21:15:51 UTC
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

Comment 1 Christian Stadelmann 2014-10-06 22:22:38 UTC
It seems like /etc/profile is not run on login.

Comment 2 Christian Stadelmann 2014-10-17 09:06:43 UTC
There are similar bugs reported upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=736660
https://bugzilla.gnome.org/show_bug.cgi?id=738336

Comment 3 Martin Meyer 2015-01-02 14:34:45 UTC
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

Comment 4 Christian Stadelmann 2015-04-09 15:20:08 UTC
Still present on F22 alpha. Note that this may trigger many more problems when applications rely on environment variables.

Comment 5 Christian Stadelmann 2015-11-14 11:40:25 UTC
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

Comment 6 Christian Stadelmann 2015-11-25 12:24:34 UTC
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.

Comment 7 Mantas M. (grawity) 2016-03-07 06:03:31 UTC
(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

Comment 8 Christian Stadelmann 2016-03-07 10:04:25 UTC
(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.

Comment 9 Mantas M. (grawity) 2016-03-07 10:59:23 UTC
(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.)

Comment 10 Christian Stadelmann 2016-03-07 15:55:22 UTC
(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.

Comment 11 Paul Eggert 2016-09-08 15:46:56 UTC
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.

Comment 12 Christian Stadelmann 2016-09-08 16:34:18 UTC
(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.

Comment 13 Paul Eggert 2016-09-08 22:45:45 UTC
(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.

Comment 14 Roger Odle 2016-09-10 14:19:58 UTC
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.

Comment 15 Paul Eggert 2016-09-10 19:21:23 UTC
(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.

Comment 16 Ray Strode [halfline] 2016-09-12 14:15:11 UTC
> > 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

Comment 17 srakitnican 2016-10-02 06:16:25 UTC
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?

Comment 18 Andy Wang 2016-11-11 19:14:25 UTC
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.

Comment 19 Glen Turner 2016-11-18 00:41:20 UTC
Note that .~/bash_profile can do more than set environment variables. Perhaps more worrying is ~/.bash_logout, which commonly runs "sudo -k".

Comment 20 J. Haas 2016-11-21 08:47:22 UTC
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.

Comment 21 Emmanuel Touzery 2016-11-25 14:54:08 UTC
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

Comment 22 Christian Stadelmann 2016-11-25 15:21:31 UTC
(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.

Comment 23 Emmanuel Touzery 2016-11-25 20:02:42 UTC
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 :-(

Comment 24 D. Hugh Redelmeier 2016-11-27 03:15:53 UTC
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.

Comment 25 Debarshi Ray 2016-11-29 15:31:50 UTC
*** Bug 1397573 has been marked as a duplicate of this bug. ***

Comment 26 Erik Bartoš 2016-12-01 08:45:24 UTC
I can confirm on Fedora 25 Workstation.

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

Comment 27 Kamil Páral 2016-12-01 11:26:20 UTC
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.

Comment 28 Jens Petersen 2016-12-05 03:50:38 UTC
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)?

Comment 29 Jens Petersen 2016-12-05 05:10:31 UTC
~/.config/systemd/user.conf does not seem to support setting DefaultEnvironment in F25 at least.

Comment 30 Debarshi Ray 2016-12-05 14:13:05 UTC
*** Bug 1398269 has been marked as a duplicate of this bug. ***

Comment 31 Nadav Har'El 2016-12-07 13:11:50 UTC
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).

Comment 32 Berend De Schouwer 2016-12-07 13:52:06 UTC
(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'.

Comment 33 Fedora Update System 2017-01-05 21:32:33 UTC
gnome-session-3.22.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-44bc42c388

Comment 34 Fedora Update System 2017-01-06 23:20:22 UTC
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

Comment 35 Richard Schwarting 2017-01-07 02:15:19 UTC
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

Comment 36 srakitnican 2017-01-07 06:36:47 UTC
(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

Comment 37 Christian Klomp 2017-01-10 20:16:43 UTC
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.

Comment 38 Christian Klomp 2017-01-12 12:35:04 UTC
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

Comment 39 Fedora Update System 2017-01-16 15:19:28 UTC
gnome-session-3.22.2-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-84b0233854

Comment 40 Fedora Update System 2017-01-16 22:24:38 UTC
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

Comment 41 David H. Gutteridge 2017-01-17 02:58:15 UTC
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.)

Comment 42 Kamil Páral 2017-01-17 08:13:30 UTC
(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.

Comment 43 Fedora Update System 2017-01-17 19:53:07 UTC
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.

Comment 44 "FeRD" (Frank Dana) 2017-01-18 12:54:21 UTC
I updated https://fedoraproject.org/wiki/Common_F25_bugs#gnome-login-shell to indicate that the fix has been released to stable.

Comment 45 Joachim Frieben 2017-01-18 19:04:37 UTC
*** Bug 1314964 has been marked as a duplicate of this bug. ***

Comment 46 Ihar Hrachyshka 2017-04-10 16:51:19 UTC
> 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.

Here I am, with my note.

[ihrachys@laptop ~]$ rpm -q gnome-session
gnome-session-3.22.3-1.fc25.x86_64

My .bash_profile at: https://github.com/booxter/homedir/blob/cc59ac1296358f492258ada37d1c5976849d8b72/.bash_profile

This didn't initialize e.g. goto or haven't included ~/bin into PATH when I open a new gnome-terminal session in Wayland.

This "fixed" the issue for me: https://github.com/booxter/homedir/commit/469019cafbbd8763653a79025d089debee95e58f

Seems like .bash_profile is still ignored by gnome-session.


Note You need to log in before you can comment on or make changes to this bug.