No Wayland desktop reached when user shell is not "bash"

[RafaelLinux]

Yesterday, I solved for another Linux (specifically openSUSE) user a problem that was also a headache for me months ago. Coincidentally, I found the solution to my problem thanks to another user who had the same problem as me before. This problem was that when trying to use Wayland for the first time, he was frustrated because after the authentication screen, instead of the Plasma desktop, a black screen appeared. The system wasn't crashing, it was just impossible to do anything. This user commented that after uninstalling the "fish" shell, the problem was solved, and as I also had it installed, I did the same and, voila, the Plasma desktop appeared using Wayland.

After some research, what I found out is that all users (of any distribution) using a shell other than "Bash", have the same problem when trying to use a session with the Wayland protocol.

At this point, and after comments from other developers, they suggest that the problem is SSDM, so I open this thread hoping that you shed light on this problem and that, if it is a bug in SSDM, it will be solved as soon as possible, since the affected users are wasting time looking for solutions in Wayland forums, KDE forums and the different shells.

I look forward to hearing from you.

Thanks

[Vogtinator]

See #1059.

Is this about using fish as login shell or as /bin/sh?

[RafaelLinux]

I installed "fish" from repositories and then changed with chsh -s /bin/fish as other fish-shell users affected by this issue.

[Vogtinator]

I finally had a look and reproduced the issue locally. FWICT, the implementation of the xsession and wayland-session scripts is just wrong. Instead of actually invoking a login shell, it sources the profile files itself as /bin/sh, then tries to get the environment of the configured login shell, imports that into its /bin/sh environment and then execs the session process.

In this particular case, re-importing the fish environment into bash fails because it tries to set the $PROFILEREAD variable, which is readonly.

Instead of re-importing the environment, the session process should be executed by the login shell itself.

[Vogtinator]

FTR, the reason that the X11 session works is that openSUSE has a downstream script for X11 which does it correctly (/usr/etc/X11/xdm/Xsession)

[RafaelLinux]

So, that means I should ask to openSUSE to create a downstream script for Wayland??? Cause I really still don't know who should fix it following your detailed explanation.

[Vogtinator]

It definitely needs to be fixed here in sddm.

[RafaelLinux]

Thank you. So, I understand I must leave this issue open.

[davidedmundson]

What's the downstream patch?

Personally I'd be happy to force running this through sh.
If users have other custom envs they can force them with relevant systemd settings than re-using the shell launch scripts.

[Vogtinator]

What's the downstream patch?

Not a patch, sddm uses the downstream Xsession script shared by all DMs on openSUSE (/usr/etc/X11/xdm/Xsession) which handles fish correctly.

This patch should fix this particular case in SDDM, but I'm still not entirely sure what the correct behaviour is.

FWICT this script only exists to run the wayland session in the environment of the login shell, but if the login shell is not POSIX compliant also with /etc/profile sourced before...

diff --git a/data/scripts/wayland-session b/data/scripts/wayland-session
index bbeb7ce..2b8c695 100755
--- a/data/scripts/wayland-session
+++ b/data/scripts/wayland-session
@@ -32,10 +32,8 @@ case $SHELL in
   */fish)
     [ -f /etc/profile ] && . /etc/profile
     [ -f $HOME/.profile ] && . $HOME/.profile
-    xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`
-    $SHELL --login -c "/bin/sh -c 'export -p' > $xsess_tmp"
-    . $xsess_tmp
-    rm -f $xsess_tmp
+    export SHELL=$SDDM_USER_SHELL
+    exec $SHELL --login -c 'exec $argv' $@
     ;;
   *) # Plain sh, ksh, and anything we do not know.
     [ -f /etc/profile ] && . /etc/profile

This way of starting the session should be generally used for all shells, but csh does not support invocation with -l -c so the bash specific exec -l function would be needed to invoce csh as -csh for triggering login shell behaviour.

Personally I'd be happy to force running this through sh.
If users have other custom envs they can force them with relevant systemd settings than re-using the shell launch scripts.

Same. IMO the login shell environment should not be necessary for graphical sessions and this script should just do exec /bin/sh --login -c 'exec $@' $@

[novaTopFlex]

As an Ubuntu user with various shells installed, I was able to successfully operate Wayland sessions on SDDM nearly as well as I could Xorg. Even though I have different shells installed (csh, ksh, ash, tcsh, fish, fizsh, xonsh, rush, yash, etc.) and do not understand if I am on bash or dash, I was able to operate my Wayland sessions because I did not change my user shell. If you have installed a newer version of bash from the GNU repositories to /usr/local/bin/bash, Wayland sessions may or may not operate correctly, so your mileage may vary even if bash is installed on your system.

[Vogtinator]

Yes, this is only broken if your /bin/sh is bash, /etc/profile or ~/.profile set a readonly variable and the user's login shell is fish, csh or tcsh.

[Vogtinator]

To summarize:

The session scripts attempt to read /etc/profile as well as the startup environment of the user's login shell. Presumably this is to combine compatibility with software only using /etc/profile (like flatpak) and user provided config which might only be added to the login shell specific startup code.

However, when using a non-POSIX login shell, it's not able to read /etc/profile on its own and hacks are used, like invoking the login shell to export its environment variables, to then import it into the POSIX sh environment. This comes with some issues: The mixed environment might not make sense anymore and importing might fail, e.g. due to readonly variables.

I see two options:

a) Remove support for non-POSIX login shell startup scripts, i.e. handle /etc/profile only. Variables in .cshrc or config.fish will have no effect.

b) Avoid the re-import of variables into sh by using the user's login shell as final command to start the session. This is what I suggested in #1768 (comment). For Xsession there would be a behaviour change: Currently the login shell environment is imported before scripts like ~/.xsession are evaluated. This order would change. This is the approach also used by xdm's Xsession script on openSUSE and appears to work fine.

b sounds like the better option to me and isn't hard to implement (-> #1779).

PS: If I'm not mistaken, the current code for zsh does not import /etc/profile, only .zshrc. Do we want to change that, to ensure that /etc/profile is imported in all cases?