I'm not 100% sure if sddm is actually the cause of my problem, but it's the most likely one. Since upgrading from x11-misc/sddm-0.18.1-r8 to x11-misc/sddm-0.20.0-r1 I cannot start any GUI applications anymore (besides the ones from autostart). When trying to run a GUI application it shows the error "Authorization required, but no authorization protocol specified" xauth info as normal user gave me this: xauth: file /tmp/xauth_LNKjfY does not exist Authority file: /tmp/xauth_LNKjfY File new: yes File locked: no Number of entries: 0 Changes honored: yes Changes made: no Current input: (argv):1 Then I also found out that the X server is started by sddm using an authority file in /run/sddm/ which obviously doesn't match the one in /tmp/. I got the current running session working by creating an authority file with the same MIT-MAGIC-COOKIE as in the /run/sddm authority file. But that's only a temporary solution. Unfortunately I cannot tell how that used to be with older sddm versions, since it simply worked for me. I started out hunting this bug in this forums post: https://forums.gentoo.org/viewtopic-p-8801025.html.
I also discovered sddm-0.20.0-r1 fails to launch fully. When sddm starts I end up in vt2 not vt7, with the vt2 console login prompt still visible plus a xserver mouse cursor. The sddm-0.18.1-r8 version logs show a cookie added in /var/run/sddm/: [19:19:33.308] (II) DAEMON: Adding new display on vt 7 ... [19:19:33.308] (II) DAEMON: Loading theme configuration from "" [19:19:33.308] (II) DAEMON: Display server starting... [19:19:33.308] (II) DAEMON: Adding cookie to "/var/run/sddm/{2e2ea732-dc3c-42ff-8157-2e8151d31408}" [19:19:33.372] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{2e2ea732-dc3c-42ff-8157-2e8151d31408} -background none -noreset -displayfd 17 -seat seat0 vt7 [19:19:35.364] (II) DAEMON: Setting default cursor [19:19:35.436] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup" [19:19:35.441] (II) DAEMON: Display server started. [19:19:35.441] (II) DAEMON: Socket server starting... [19:19:35.442] (II) DAEMON: Socket server started. [19:19:35.442] (II) DAEMON: Loading theme configuration from "" [19:19:35.442] (II) DAEMON: Greeter starting... [19:19:35.472] (II) HELPER: [PAM] Starting... [19:19:35.472] (II) HELPER: [PAM] Authenticating... [19:19:35.472] (II) HELPER: [PAM] returning. [19:19:35.502] (II) DAEMON: Greeter session started successfully The sddm-0.20.0-r1 version sets a cookie in /run/sddm/, does not set a session seat and fails to authenticate with PAM: [19:07:21.714] (II) DAEMON: Initializing... [19:07:21.720] (II) DAEMON: Starting... [19:07:21.720] (II) DAEMON: Logind interface found [19:07:21.720] (II) DAEMON: Adding new display... [19:07:21.720] (II) DAEMON: Loaded empty theme configuration [19:07:21.721] (II) DAEMON: Xauthority path: "/run/sddm/xauth_DgjiFw" [19:07:21.721] (II) DAEMON: Using VT 2 [19:07:21.721] (II) DAEMON: Display server starting... [19:07:21.721] (II) DAEMON: Writing cookie to "/run/sddm/xauth_DgjiFw" [19:07:21.721] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_DgjiFw -noreset -displayfd 16 [19:07:23.768] (II) DAEMON: Setting default cursor [19:07:23.832] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup" [19:07:23.843] (II) DAEMON: Display server started. [19:07:23.843] (II) DAEMON: Socket server starting... [19:07:23.843] (II) DAEMON: Socket server started. [19:07:23.843] (II) DAEMON: Loaded empty theme configuration [19:07:23.843] (II) DAEMON: Greeter starting... [19:09:55.168] (WW) DAEMON: Signal received: SIGTERM [19:09:55.168] (II) DAEMON: Socket server stopping... [19:09:55.168] (II) DAEMON: Socket server stopped. [19:09:55.168] (II) DAEMON: Display server stopping... [19:09:55.194] (II) DAEMON: Display server stopped. [19:09:55.194] (II) DAEMON: Running display stop script ("/usr/share/sddm/scripts/Xstop") [19:09:55.195] (WW) HELPER: Signal received: SIGTERM [19:09:55.195] (WW) HELPER: [PAM] Asked to close the session but it wasn't previously open [19:09:55.196] (WW) DAEMON: Auth: sddm-helper exited with 255 If I restart the display-manager service then surprisingly sddm-0.20.0-r1 launches - but I haven't looked into it because having to login in a console to restart the display-manager every time negates the need for a DM altogether. I'll hold back updating sddm on other systems to avoid annoying other users. Please ask if you need more info.
(In reply to MickKi from comment #1) > I also discovered sddm-0.20.0-r1 fails to launch fully. When sddm starts I > end up in vt2 not vt7, with the vt2 console login prompt still visible plus > a xserver mouse cursor. I end up with X fully running in vt2, while vt7 only shows a blinking cursor. That doesn't annoy me by itself, but if it's related to the xauth issue, then it should be fixed, too. > If I restart the display-manager service then surprisingly sddm-0.20.0-r1 > launches - but I haven't looked into it because having to login in a console > to restart the display-manager every time negates the need for a DM > altogether. I'll hold back updating sddm on other systems to avoid > annoying other users. Please ask if you need more info. I haven't tried that yet. Of course I would be interested in a bug fix. :)
It seems USE="pam" is no longer needed? [U] x11-misc/sddm Available versions: 0.18.1-r8 ^t [+elogind +pam systemd test] ["?? ( elogind systemd )"] 0.20.0-r1 ^t [+elogind systemd test] ["^^ ( elogind systemd )"] Installed versions: 0.18.1-r8^t(19:17:54 09/07/23)(elogind pam -systemd -test) Homepage: https://github.com/sddm/sddm Description: Simple Desktop Display Manager Indeed, there are load of pam related patch files which are no longer included in 0.20.0-r1. Also, I see in README.md "SDDM is assumed to start at the tty specified by the cmake variable SDDM_INITIAL_VT which is an integer and defaults to 1" - not sure how this explains why in my case sddm-0.20.0-r1 tries to start on vt2 but its login GUI never launches.
I had a look at this again today. On a working system sddm-0.20.0-r1 launches fully in vt2 at boot. There are two identical entries in /run and in /var/run: drwx--x--x 2 root root 60 Sep 21 15:22 sddm -rw-r--r-- 1 root root 5 Sep 21 15:22 sddm.pid There are a number of entries in /tmp. Specifically,: $ ls -la /tmp/ | grep sddm srwxrwxrwx 1 sddm sddm 0 Sep 21 15:33 dbus-TQVAKAFiSM srwx------ 1 sddm sddm 0 Sep 21 15:33 sddm-:0-xHJXQh srwxr-xr-x 1 root root 0 Sep 21 15:33 sddm-auth-5a585588-c38d-4512-bec8-cf1473e3ed43 -rw------- 1 sddm sddm 94 Sep 21 15:33 xauth_NwSVAO On the non-working system sddm-0.20.0-r1 only partially launches at boot on vt2. Only a mouse shows up, no login field, sddm buttons, or wallpaper. Looking at /run and /var/run the same entries as in the working system show up, however, the entries in /tmp are incomplete. There is no sddm dbus socket, no sddm-auth-xxxxx socket and no sddm xauth_xxxx file. Only the sddm-:0-xxxxx socket is created. If I restart the display-manager service, then sddm launches on vt7 as it used to do with version 0.18.1-r8 and the missing files and sockets are created in /tmp. Please ask if you need more info, or if there is a permanent workaround I could implement to get sddm launching fully at boot to allow me to login, without me having to restart the display-manager each time.
I had to reboot, which I do rarely. When I tried to logon from sddm to Plasma(X11) nothing happened, the sddm screen just sat there. Switching to a console and looking at the running processes, the xserver hadn't started. I tried another account, which was never used, and the xserver did start. So I copied the files in my home directory to the new one and, lo, sddm wouldn't work again. I deleted all the files in the new account and now the xserver started. So I thought, some file has got corrupted by the power loss (I do use ext4, but whatever) so I restored from a backup taken before the domestic mishap. My old userid wouldn't get an X session. So I made a fresh user and started customising it manually. After I had done a fair amount of customisation, sddm stopped loading the xserver. I had the idea to try startx: the xserver started and twm leapt into life! So it looks like the issue is sddm. ~/.local/share/sddm/xorg-session.log contains: Authorization required, but no authorization protocol specified Authorization required, but no authorization protocol specified xrdb: Resource temporarily unavailable xrdb: Can't open display ':0' Authorization required, but no authorization protocol specified xfce4-session: Cannot open display: . Type 'xfce4-session --help' for usage. Here I was trying xfce, but none of the desktops work.
Any news on this bug?
Please test with 0.21.0.
(In reply to Andreas Sturmlechner from comment #7) > Please test with 0.21.0. Tested sddm-0.21.0 just now, this version works fine. :-) Thanks.
(In reply to MickKi from comment #8) > (In reply to Andreas Sturmlechner from comment #7) > > Please test with 0.21.0. > > Tested sddm-0.21.0 just now, this version works fine. :-) > > Thanks. Ugh! Spoke too fast - sorry. Before I posted I had logged out, restarted sddm and was able to get the DM login on VT7. However, after a reboot sddm launches partly on VT2 and it still fails with a black screen, cursor at top left, mouse cursor in the middle of the screen. PAM does not kick in, sddm greeter never launches fully unless I restart the display-manager service. :-( I'm back on sddm-0.18.1-r8. PS. I wonder, could this problem have something to do with /home being on a luks partition and argon2 iterations taking too long for sddm's liking? :-/
I also tried with DisplayServer=x11-user, as well as DisplayServer=wayland, using weston or kwin_wayland with the settings provided in the wiki sddm page. No sddm configuration allows me to launch sddm, or when it does launch upon reboot with wayland, then login is not processed once I enter the user password. Curiously, when I restart display-manager with wayland then sddm crashes. The only way to be able to login with versions >sddm-0.18.1-r8 and default settings is first to login as root in a VT and restart display-manager. I don't understand why sddm x11 won't launch fully at boot, but does after the display-manager service is restarted manually. :-/
> > PS. I wonder, could this problem have something to do with /home being on a > luks partition and argon2 iterations taking too long for sddm's liking? :-/ I don't use luks, so that can't be the reason. Haven't tested 0.21 yet though.
I saw sddm-0.21.0 was marked as stable, so I gave it another spin. My system has now migrated to profile 23.0 and a merged-usr, running a Plasma Wayland desktop. I tried sddm-0.21.0 with no config - default settings. sddm launches and allows me to enter passwd. Then sddm appears to hanging. The breeze theme shows all buttons going grey, along with the passwd field. No further input is possible and a Plasma wayland desktop won't launch. I can escape to a VT with Ctrl+F1, where 'rc-service -v display-manager status' shows "started" and the sddm log contains this: [14:59:05.429] (II) DAEMON: Initializing... [14:59:05.431] (II) DAEMON: Starting... [14:59:05.431] (II) DAEMON: Logind interface found [14:59:05.432] (II) DAEMON: Adding new display... [14:59:05.432] (II) DAEMON: Loaded empty theme configuration [14:59:05.433] (II) DAEMON: Xauthority path: "/run/sddm/xauth_bGjqNx" [14:59:05.433] (II) DAEMON: Using VT 2 [14:59:05.433] (II) DAEMON: Display server starting... [14:59:05.433] (II) DAEMON: Writing cookie to "/run/sddm/xauth_bGjqNx" [14:59:05.433] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_bGjqNx -noreset -displayfd 16 [14:59:05.829] (II) DAEMON: Setting default cursor [14:59:05.834] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup" [14:59:05.836] (II) DAEMON: Display server started. [14:59:05.836] (II) DAEMON: Socket server starting... [14:59:05.836] (II) DAEMON: Socket server started. [14:59:05.836] (II) DAEMON: Loading theme configuration from "/usr/share/sddm/themes/breeze/theme.conf" [14:59:05.837] (II) DAEMON: Greeter starting... [14:59:05.842] (II) HELPER: [PAM] Starting... [14:59:05.842] (II) HELPER: [PAM] Authenticating... [14:59:05.842] (II) HELPER: [PAM] returning. [14:59:05.852] (II) HELPER: Writing cookie to "/tmp/xauth_dBqTnm" [14:59:05.852] (II) HELPER: Starting X11 session: "" "/usr/bin/sddm-greeter --socket /tmp/sddm-:0-KwRtvy --theme /usr/share/sddm/themes/breeze" [14:59:05.853] (II) DAEMON: Greeter session started successfully [14:59:05.885] (II) DAEMON: Message received from greeter: Connect [15:00:55.867] (II) DAEMON: Message received from greeter: Login [15:00:55.868] (II) DAEMON: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop" [15:00:55.869] (II) DAEMON: Session "/usr/share/wayland-sessions/plasmawayland.desktop" selected, command: "/usr/lib64/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland" for VT 7 If I restart the display-manager service from a VT, then two things happen. The sddm greeter crashes as it tries to stop, with this message in the log: [15:01:38.772] (WW) DAEMON: Signal received: SIGTERM [15:01:38.772] (II) DAEMON: Greeter stopping... [15:01:38.772] (WW) HELPER: Signal received: SIGTERM [15:01:43.777] (WW) HELPER: Signal received: SIGTERM [15:01:43.777] (WW) HELPER: [PAM] Asked to close the session but it wasn't previously open [15:01:43.782] (WW) DAEMON: Auth: sddm-helper exited with 255 [15:01:43.782] (II) DAEMON: Socket server stopping... [15:01:43.782] (II) DAEMON: Socket server stopped. [15:01:43.782] (II) DAEMON: Display server stopping... [15:01:43.816] (II) DAEMON: Display server stopped. [15:01:43.816] (II) DAEMON: Running display stop script ("/usr/share/sddm/scripts/Xstop") [15:01:43.818] (II) DAEMON: Greeter stopping... [15:01:43.818] (WW) DAEMON: Error from greeter session: "Process crashed" [15:01:43.818] (WW) DAEMON: Auth: sddm-helper (--socket /tmp/sddm-auth-42385666-737f-45d8-990a-a794490e8cd0 --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-KwRtvy --theme /usr/share/sddm/themes/breeze --user sddm --greeter) crashed (exit code 1) [15:01:43.818] (WW) DAEMON: Error from greeter session: "Process crashed" [15:01:43.818] (WW) DAEMON: Auth: sddm-helper exited with 9 [15:01:43.818] (II) DAEMON: Greeter stopped. SDDM::Auth::HelperExitStatus(9) As it restarts the display-manager service launches sddm, allows me to enter my passwd and this time a Plasma Wayland session starts without any further problems, e.g.: [15:23:44.017] (II) DAEMON: Initializing... [15:23:44.019] (II) DAEMON: Starting... [15:23:44.019] (II) DAEMON: Logind interface found [15:23:44.019] (II) DAEMON: Adding new display... [15:23:44.019] (II) DAEMON: Loaded empty theme configuration [15:23:44.020] (II) DAEMON: Xauthority path: "/run/sddm/xauth_nWCdUN" [15:23:44.020] (II) DAEMON: Using VT 7 [15:23:44.020] (II) DAEMON: Display server starting... [15:23:44.020] (II) DAEMON: Writing cookie to "/run/sddm/xauth_nWCdUN" [15:23:44.020] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt7 -auth /run/sddm/xauth_nWCdUN -noreset -displayfd 16 [15:23:44.329] (II) DAEMON: Setting default cursor [15:23:44.332] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup" [15:23:44.333] (II) DAEMON: Display server started. [15:23:44.333] (II) DAEMON: Socket server starting... [15:23:44.333] (II) DAEMON: Socket server started. [15:23:44.333] (II) DAEMON: Loading theme configuration from "/usr/share/sddm/themes/breeze/theme.conf" [15:23:44.334] (II) DAEMON: Greeter starting... [15:23:44.337] (II) HELPER: [PAM] Starting... [15:23:44.338] (II) HELPER: [PAM] Authenticating... [15:23:44.338] (II) HELPER: [PAM] returning. [15:23:44.355] (II) HELPER: Writing cookie to "/tmp/xauth_gNQcxF" [15:23:44.355] (II) HELPER: Starting X11 session: "" "/usr/bin/sddm-greeter --socket /tmp/sddm-:0-DguvBb --theme /usr/share/sddm/themes/breeze" [15:23:44.356] (II) DAEMON: Greeter session started successfully [15:23:44.373] (II) DAEMON: Message received from greeter: Connect [15:23:50.206] (II) DAEMON: Message received from greeter: Login [15:23:50.206] (II) DAEMON: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop" [15:23:50.206] (II) DAEMON: Session "/usr/share/wayland-sessions/plasmawayland.desktop" selected, command: "/usr/lib64/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland" for VT 8 [15:23:50.216] (II) HELPER: [PAM] Starting... [15:23:50.216] (II) HELPER: [PAM] Authenticating... [15:23:50.216] (II) HELPER: [PAM] Preparing to converse... [15:23:50.216] (II) HELPER: [PAM] Conversation with 1 messages [15:23:50.219] (II) HELPER: [PAM] returning. [15:23:50.219] (II) DAEMON: Authentication for user "michael" successful [15:23:50.253] (II) HELPER: Starting Wayland user session: "/usr/share/sddm/scripts/wayland-session" "/usr/lib64/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland" [15:23:50.253] (II) HELPER: Jumping to VT 8 [15:23:50.253] (II) HELPER: VT mode didn't need to be fixed [15:23:50.255] (II) HELPER: [PAM] Closing session [15:23:50.256] (II) HELPER: [PAM] Ended. [15:23:50.257] (II) DAEMON: Auth: sddm-helper exited successfully [15:23:50.257] (II) DAEMON: Greeter stopped. SDDM::Auth::HELPER_SUCCESS [15:23:50.317] (II) DAEMON: Session started true I cannot understand why sddm works after a restart of the display-manager, but not after a reboot. :-/ I also tried configuring sddm to use DisplayServer=wayland, both after installing weston and by using kwin, the latter with the following config additions: [General] GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell DisplayServer=wayland # Remove qtvirtualkeyboard as InputMethod default InputMethod= [Wayland] CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 sddm starts, I can add a passwd, but then it hangs as above. Restarting it does not allow me to login. Since sddm using wayland is still experimental, I'm only mentioning it here peripherally.
Other distros have been affected too and reports upstream on github are seeking to resove this: https://github.com/sddm/sddm/issues/1844 https://github.com/sddm/sddm/pull/1896 However, I still can't explain why I encountered this problem on one PC only and not on other systems which are also run Plasma Wayland desktops. :-/
