Sway: /etc/profile is never sourced when launching sway from GDM

[asppsa]

Hi,

I found that when launching Sway from GDM on Archlinux, the /etc/profile file never gets sourced. I'm not sure if this counts as a bug, as the behaviour is the same for other wayland sessions that I tried, like Weston (but not Gnome, for some reason), and its only a problem when launching from a graphical login manager, as otherwise the profile is sourced already (e.g. when logging into a TTY). My sway version:

~
sway version 1.0-beta.1-157-g994c35e3 (Nov 6 2018, branch 'master')
~

To verify, you could do something like edit /etc/profile and add export MY_VARIABLE=1 to that file. Then login via GDM with Sway, launch a terminal and check to see if MY_VARIABLE is set. In my tests, it is not.

I have been able to solve this by changing the Exec=sway line in sway.desktop to Exec=bash -l -c sway. This launches a login shell (which sources the profile) and then runs sway inside of the shell. This is enough for my purposes, but I'm not sure if this is the correct way to fix this (or even if this warrants fixing) ... at any rate I figured I would report it.

[emersion]

This happens because GDM doesn't start a shell. This is normal behaviour, and we can't do anything about it.

Why do you need to source /etc/profile?

[asppsa]

Hi, thanks for getting back so fast.

The reason I wanted this sourced is that on Arch Linux, a bunch of environment vars get set by files in /etc/profile.d (mostly not too important, but there is the occasional thing of significance in there, like setting up Java paths). However, if you feel this is not Sway's job to fix, I understand.

[emersion]

The reason I wanted this sourced is that on Arch Linux, a bunch of environment vars get set by files in /etc/profile.d (mostly not too important, but there is the occasional thing of significance in there, like setting up Java paths). However, if you feel this is not Sway's job to fix, I understand.

This shouldn't matter, because when you run exec in the sway config, a shell is used so the profile is sourced.

[emersion]

To verify, you could do something like edit /etc/profile and add export MY_VARIABLE=1 to that file. Then login via GDM with Sway, launch a terminal and check to see if MY_VARIABLE is set. In my tests, it is not.

Wait, this should work. What is your /bin/sh?

[asppsa]

My understanding is that profile files (/etc/profile, ~/.bash_profile, etc.) are only sourced by login shells (e.g. bash -l). .bashrc would be sourced for every exec, so I could of course add something there to source /etc/profile. My actual solution (changing the Exec= line) seems to work better than this though (although it won't source my .zprofile if I had one).

I'm using zsh, but as you ask about /bin/sh:

~~~
$ /bin/sh --version
GNU bash, version 4.4.23(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
~~~

I also found this discussion of the same issue with relation to the same issue in Gnome under wayland. It looks like there they have some code inside of the gnome-session bash script which relaunches the script in a login shell when wayland is in play.

[emersion]

Ah, right, this makes sense.

GNOME has gnome-session which calls gnome-session-binary. You could setup sway like this too (e.g. I have sway-run which calls sway).

[asppsa]

Yes, that sounds like a plan. Thanks for your help.

[asbachb]

Is there any working example? I tried:

cat /usr/share/wayland-sessions/sway.desktop                                                                                                                                         :(
[Desktop Entry]
Name=Sway
Comment=An i3-compatible Wayland compositor
Exec=/usr/bin/zsh -l -c sway
Type=Application

Without success.

[asppsa]

I am using:

Desktop file:

``` sway-in-shell.desktop
[Desktop Entry]
Name=Sway (in login shell)
Comment=SirCmpwn's Wayland window manager
Exec=/usr/local/bin/sway-in-shell
Type=Application

`/usr/local/bin/sway-in-shell`:

```bash
#!/bin/sh

if [ "x$XDG_SESSION_TYPE" = "xwayland" ] &&
   [ "x$XDG_SESSION_CLASS" != "xgreeter" ] &&
   [  -n "$SHELL" ] &&
   grep -q "$SHELL" /etc/shells &&
   ! (echo "$SHELL" | grep -q "false") &&
   ! (echo "$SHELL" | grep -q "nologin"); then
  if [ "$1" != '-l' ]; then
    exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"
  else
    shift
  fi
fi

exec /usr/bin/sway "$@"

sway-in-shell is more or less a carbon copy of the equivalent GNOME file.

[ispanos]

Is there any working example? I tried:

cat /usr/share/wayland-sessions/sway.desktop                                                                                                                                         :(
[Desktop Entry]
Name=Sway
Comment=An i3-compatible Wayland compositor
Exec=/usr/bin/zsh -l -c sway
Type=Application

Without success.

I just tried that and it works. I have a ~/.zprofile (same as my .profile) which got sourced properly. I also check one of the scripts in /etc/profile.d/ and it also got sourced.

[blaggacao]

I thought this environment.d based "solution" might be useful in this context. It avoids *profile* altogether: https://github.com/swaywm/sway/issues/5160#issuecomment-645487492

I moved all reasonable environment definitions (PATH(s), EDITOR, etc) in ~/.config/environment.d/*.conf files.

[daboross]

Is there any plan to support this officially in any way? Starting out interacting with a new WM by having to manually edit the .desktop file installed by the package manager isn't the greatest experience. Or is the correct solution to use another login manager - if so, which one?

I feel like this should be supported in some sense because as I understand it, ~/.profile is the standard way to set env vars for all login environments, not just shells. I use it mainly to modify my PATH so that any/all programs installed in ~/.local/bin will be available to launch, and I thought this was fairly standard. Not a super drop in replacement for i3 if I can't even launch my app launcher because it's no longer in my path.

Apologies if this is a bit ranting - I appreciate sway existing, and I don't mean to rag on this one thing. Just a bit annoying to try a new thing & immediately run into a closed issue where the solution is modifying system files installed by sway.

[emersion]

This is a display manager bug. Users logging in via fbcon get their profile sourced, the same should happen when running from a display manager.

FWIW, display managers aren't officially supported by Sway because of bugs like this.

[daboross]

Cool, thanks - that's what I wanted to know.