Dear Maintainer, When installing Debian by picking LXQT in the Desktop Environment selection of the installer (didn't test with other configurations), I got SDDM to break by doing the following right after the install: - Log in my session - Wait for things to load - Log out After doing this, I got stuck with a black scren and a mouse cursor (which could move) I also went into a text tty and restarted sddm through systemctl which resulted in a functional sddm again. However, sddm.log is empty, and the Xorg log file doesn't seem to show any signs of error. Thanks for taking this report in account!
Under normal circumstances, when sddm starts up properly, I get in journalctl the log linked as "normal-sddm.txt" After logging out, I get in journalctl (only for sddm) the log contained in "broken-sddm.txt" I am also the log of sddm in jounalctl directly after starting to login in the file "login-sddm.txt" For this last log file I decided to include not only lines containing sddm, but rather all the lines in the journal until the full session opened.
Hey, from the logs the problem is that the greeter cannot connect to the socket. " Socket error: "QLocalSocket::connectToServer: Invalid name" Cannot connect to the daemon - is it running?" You can see the socketname in the logs /tmp/sddm-:0-ffVDPB Tht is the same as in the normal-sddm.log - so it seems like this socket stays alave while you are logged in. Is this the case? Does restart sddm service helps? (as root: systemctl restart sddm.service) Maybe LXQT does not finish its session fast enough and some thing is still dangling around. ( search for processes that are created by you user) Do you know that a previous version of sddm that worked? Do you use systemd and loginctl? Regards, hefee
Hello, You are right, the socket stays alive during the whole session, but as soon as I close it (corresponds to the state "lc-logged-out-early.txt"), the socket disappears (no longer present in as /tmp/sddm-:0-ffVDPB) Also, sudo systemctl restart sddm.service does work and make SDDM usable again. I am using systemd and loginctl About this: I created a new account "readertest" from which I did ps -edalf after having logged out from my account that we will call "myaccount". No processes are left on average. However if I launch a big quantity of stuff, there will still be processes listed by ps -edalf dangling around and the session will still be shown as open in loginctl (whatever time I wait) However, about this: Your hypothesis seems like it's exactly what happens. Using the same "readertest" account I ran loginctl at few key moments - When the system started "lc-startup.txt" - When I logged in "lc-logged.txt" - Quickly after logging out "lc-logged-out-early(/2/3).txt" (did run it many times just to capture the advance of the log out process) - Another time after logging out, but later (around 10 seconds later) "lc-logged-out-early4.txt" As you can see, even though sddm started back agai n my session is still running, for a long time. But even if my session is still running, the socket disappeared. Unfortunately, I don't know any version of sddm when it worked before. Regards.
Hello again,
I did a little bit of investigation and noticed some things:
* The bug doesn't happen in a virtual machine, whether it is on Debian
Bookworm, Trixie or Sid
* The bug seems to happen on my machine, regardless of whether it was
on Trixie or Sid
* No changes when changing SDDM config to use x11, x11-user or even
x11-wayland
* Using the maui theme instead of the default debian-breeze theme
didn't change anything
* There is no issue when using a different DE
I have recompiled sddm using the sources from apt, and I was able to
gather a real sddm.log file that I am attaching to this message with the
hope it will help.
It should also be interesting to note that I have an AMD integrated GPU
and that there are few upstream issues which already look like mine:
https://github.com/sddm/sddm/issues/1535
https://github.com/sddm/sddm/issues/2134
(also with interestingly the same CPU and the same warnings about random
number generation)
Hope this helps!
I will continue to search later on if anything can fix this issue, now
that I can also directly patch the source code.
Hey, I managed to find the SDDM bug causing the issues when logging out. I created a pull request upstream: https://github.com/sddm/sddm/pull/2205 It fixes the bug entirely on my machine. The bug was because when logging out there can be a race condition where the new server socket of the SDDM daemon starts before the old server socket gets closed and deleted. The fix will explicitly close the server socket before opening a new one. Regards.
Hey, thx for all your work you put into that! Thanks a lot, that you already created a MR that fixes the issue I've marked this bug as forwarded to the MR, that helps BTS to check on updates and inform this bug, if the MR get merged. As you provide other useful information, I updated the metadata for this bug. From a Debian point of view we now wait till upstream merges, before we apply patch older version. That way we make sure, that we do not fork away from upstream. Let's hope upstream reacts within a suitable time frame and we don't need to find workarounds. Regards, hefee
Hey, I wanted to add a precision about a message a sent earlier: I did not mention having tested Bookworm, not because there was no bug but rather because I didn't test. So I did tests on few other Debian versions: - Debian Stretch: No bug but the absence of amdgpu is probably what caused the bug to show in the first place, so the test looks invalid - Debian Buster: Same as Stretch - Debian Bullseye: This version is affected (tested with the same environment as Trixie, with amdgpu present) Bookworm was not tested but it is safe to assume this version is also affected. I wanted to add this precision because it directly affects Bookworm and Bullseye which are still LTS. Regards.