#1142038 sddm: SDDM breaks after logging out of session (black screen & mouse cursor only)

Package:
sddm
Source:
sddm
Description:
modern display manager for X11
Submitter:
Anonymous
Date:
2026-07-19 18:39:01 UTC
Severity:
normal
Tags:
#1142038#5
Date:
2026-07-14 07:07:02 UTC
From:
To:
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!

#1142038#10
Date:
2026-07-14 07:55:11 UTC
From:
To:
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.

#1142038#15
Date:
2026-07-15 11:17:24 UTC
From:
To:
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

#1142038#20
Date:
2026-07-16 08:38:46 UTC
From:
To:
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.

#1142038#25
Date:
2026-07-16 21:49:40 UTC
From:
To:
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.

#1142038#30
Date:
2026-07-17 11:38:55 UTC
From:
To:
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.

#1142038#37
Date:
2026-07-18 19:10:20 UTC
From:
To:
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

#1142038#48
Date:
2026-07-19 11:55:08 UTC
From:
To:
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.