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

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

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

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

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

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.

(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

(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.

(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.)

(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.

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.

(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.

(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.

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.

(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.

> > 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

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?

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.

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

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.

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

(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.

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 :-(

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.

*** Bug 1397573 has been marked as a duplicate of this bug. ***

I can confirm on Fedora 25 Workstation.

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

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.

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)?

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

*** Bug 1398269 has been marked as a duplicate of this bug. ***

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).

(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'.

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

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

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

(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

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.

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

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

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

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.)

(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.

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.

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

*** Bug 1314964 has been marked as a duplicate of this bug. ***

> 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.