XLibre session auto-logout after a time

n1ckla · February 21, 2026, 10:49am

Ever since I do a dsync on Feb 15th, 2026, I noticed something odd. First, the time needed from login to KDE to load up is much longer. Then, after it loads up, give it a minute or two, then I’m automatically kicked/logged out to the login screen. If I login again, then the load time is much faster (as it should) and it is stable.

However, if I do a logout and re-login, that cycle repeats: long KDE load, after loaded, then 1 to 2 minutes to auto logged out. Only this time, it persists. Only a reboot could somewhat remedy the problem, in that long KDE load time, loaded, then 1-2 minutes to auto-logged out, login, faster login, and stable.

I recently installed IceWM. The same cycle like KDE, so I don’t think it’s DE/WM problem. BTW, I did dsync again today (Feb 21st), but the problem persists.

Now, I try to troubleshoot the problem with Claude Sonnet 4.6 (Yeah, and AI agent), and here’s the story (a bit long):

First, from journalctl -b | grep -i "error\|fail" | less, it found that KWallet is trying to load and fail, despite I already disable it in KDE long ago, and despite I’m logging to IceWM. 1st I found this:

$ cat ~/.config/kwalletrc

[Wallet]
Close When Idle=false
Close on Screensaver=false
Default Wallet=kdewallet
Enabled=false
First Use=false
Idle Timeout=10
Launch Manager=false
Leave Manager Open=false
Leave Open=true
Prompt on Open=false
Use One Wallet=true

[org.freedesktop.secrets]
apiEnabled=true

So I edit that apiEnabled=true to false, and for good measure, do this:

systemctl --user mask kwalletd5.service
systemctl --user mask kwalletd6.service

No Improvement. Then I found this from journalctl:

p11-kit: could not bind socket /run/user/107/p11-kit/pkcs11: Unknown error 2
p11-kit-server.service: Failed with result 'exit-code'

And, X server starts twice.

And then also this:

$ ls -la /run/user/107/
ls: cannot access '/run/user/107/': No such file or directory

user 107 is the sddm.

Long story short, I found ksecretd still run as a child of SDDM. Looks like pam_kwallet5 being called during login even though I disabled KWallet.

So I do this:

sudo cp /etc/pam.d/sddm /etc/pam.d/sddm.bak
sudo nano /etc/pam.d/sddm

Comment out all three kwallet lines:

#-auth        optional      pam_kwallet5.so
#-auth        optional      pam_kwallet.so
#-session     optional      pam_kwallet5.so auto_start
#-session     optional      pam_kwallet.so auto_start

Reboot, and the same. journalctl -b | grep -i "error\|fail". The pattern is identical: p11-kit still failing on /run/user/107/ which still doesn’t exist. So I do this:

sudo mkdir -p /run/user/107/p11-kit
sudo chown -R sddm:sddm /run/user/107
sudo chmod 700 /run/user/107
sudo systemctl restart sddm

I logged out and logged in perfectly, fast load and stable. Then I check this:

$ ls -la /run/user/107/
ls: cannot access '/run/user/107/': No such file or directory

So we (me and Claude) thought the problem is /run/user/107/ is not created at the appropriate time. I tried this:

sudo loginctl enable-linger sddm

Reboot. Same, long DE/WM load time, 1-2 minutes to auto-logged out. The difference is, when kicked, the login screen doesn’t load and the PC crash. I have to hard reset. In the next login screen, I drop to TTY and do this to restore:

sudo loginctl disable-linger sddm

Reboot. Like before, long DE/WM load and 1-2 minutes till kicked. But at least this time I manage to get the login.

Now, I try to disable p11-kit altogether:

sudo mkdir -p /var/lib/sddm/.config/systemd/user
sudo ln -s /dev/null /var/lib/sddm/.config/systemd/user/p11-kit-server.service
sudo ln -s /dev/null /var/lib/sddm/.config/systemd/user/p11-kit-server.socket
sudo chown -R sddm:sddm /var/lib/sddm/.config

Reboot and still the same. But now journalctl -b | grep -i "error\|fail" reveal something else:

p11-kit is now failing for your user session (UID 1001), not just SDDM:

systemd[1305]: p11-kit-server.service: Failed with result 'exit-code'.

PID 1305 is my user’s systemd instance, not SDDM’s.

A new failure appeared:

systemd[1305]: ssh-agent.service: Failed with result 'exit-code'.

The actual session-kicking culprit is now this:

systemd[1565]: sys-devices-...-sound-card0-controlC0.device: Failed to enqueue SYSTEMD_USER_WANTS job: Transaction for sound.target/start is destructive (sound.target has 'stop' job queued)

So, I also mask p11-kit for my own user:

mkdir -p ~/.config/systemd/user
ln -s /dev/null ~/.config/systemd/user/p11-kit-server.service
ln -s /dev/null ~/.config/systemd/user/p11-kit-server.socket
ln -s /dev/null ~/.config/systemd/user/ssh-agent.service

Still the same. journalctl -b | grep -i "error\|fail"now show:

ACPI BIOS errors (pre-existing firmware bugs)
gpsd, rngd, smartd, alsa UCM (all pre-existing)
dbus-broker-launch: Activation request for 'org.freedesktop.home1' failed
WirePlumber assertions failing (4x) — this is now the most suspicious remaining error
wireplumber: Failed to get percentage from UPower
Two bare (EE) error, X server lines

After comparing the logs from failed and stable login, we came to the conclusion that WirePlumber is not causing the kick — it happens in both cases. The failed login is dying before the sound conflict even gets a chance to appear.

Something is killing the first session between 14:03:36 and when the sound errors would appear (~14:04:37). That’s roughly a 60-second window where something times out.

Seems that something is causing X to exit:

14:03:05  systemd-logind: New session 'c3' of user 'xeon' with class 'user' and type 'x11'
14:03:06  sddm-helper: Starting X11 session: "... /Xsession \"/usr/bin/icewm-session\""
14:03:06  X server terminated successfully (0)

The X server exits with code 0 (success/clean exit) immediately after your session starts. This isn’t a crash — it’s a deliberate clean exit. And the reason is right there:

sddm-helper[1282]: Starting X11 session: ... "/usr/share/X11/xdm/Xsession \"/usr/bin/icewm-session\""

OK. I’m at loss here. Of course these logs are tested on IceWM. But for a week, the same also happened in KDE. I just installed IceWM today.

Lastly, some symptom I noticed. If I reboot, login, wait to long load, then the DE/WM load, and do nothing, waiting to be kicked to login screen, the next login will also a long wait and 1-2 minute until kicked again. But, if I do something, i.e. do something in the terminal, open an app till I’m being kicked, the next login will be fast and stable.

Sorry for the long post.
Anyone has any ideas?

n1ckla · February 21, 2026, 12:59pm

I hope I’m not rude here replying to my own post. I want to add more info of what I found so far, which may be pertinent, or not. I would post the logs but it’s so much and across multiple dump files (piped from journalctl, mainly) and multiple context (try edit this and that and see what happens).

It does seem that the session is being killed by a 90-second timeout.

14:03:06  session c3 starts, IceWM launches
14:04:36  session c3 killed after exactly 1 minute 30 seconds
          Killing: Xorg, icewm-session, icewm, urxvt, bash

At least for me, the 90-second kill is real and reproducible.

14:03:06  sddm-helper[1282]: Starting X11 session: ... "/usr/bin/icewm-session"
14:04:36  sddm-helper[1282]: pam_unix(sddm:session): session closed for user xeon

Somehow, sddm-helper itself is deciding the session ended. I try this:

sudo sed -i 's/ReuseSession=true/ReuseSession=false/' /etc/sddm.conf

Rationale: SDDM may sees a previous plasma session marked as reusable, tries to reuse it, it fails or times out after 90s, then starts fresh.

Still no improvement. However, comparing multiple logs, I found this:

18:19:28  sddm-helper[1283]: Starting X11 session: ... icewm-session
18:20:58  sddm-helper[1283]: pam_unix(sddm:session): session closed for user xeon
18:20:58  sddm[1184]: Auth: sddm-helper exited with 2
18:20:58  session-c3.scope: Consumed ... over 1min 30.304s wall clock time

At least according to Claude, sddm-helper exited with 2, that Exit code 2 from sddm-helper means “authentication/session failure”, not a timeout. The X server for current session is never mentioned as stopping — it’s still running when sddm-helper gives up on it. Also, the session ran for exactly 1 minute 30 seconds again.

According to my logs, The X server started at 18:19:58 but sddm-helper started the session at 18:19:28 — that’s a 30 second gap before the X server even started. Something is blocking X from starting for 30 seconds, eating into the 90s window, and then sddm-helper times out waiting for the session to be “ready”.

Hypothesis: the 30-second delay before X starts and the exact 90-second kill strongly suggest there’s a hardcoded timeout in sddm-helper itself waiting for the session to signal “ready” via D-Bus.

However, I haven’t able to find where that “timeout” originated.

Anybody has ideas? Or am I barking at the wrong tree with this timout thing here?

schappellshow · February 21, 2026, 1:29pm

I won’t be able to help at all, but I’ve been dealing with something similar. On my ROME desktop, the issue first popped up earlier in Feb. I have a separate laptop running ROME, and this logout issue began on that device after the bigger Nov. update. There have been some other posts on the forum with similar problems reported, but I don’t think there has been a resolution yet.

I’ve found that, after being logged out to the sddm screen, I press CTRL+ALT+F4 to pop into a tty session. I then remove sddm, stop & disable it, and then reinstall it. This helps on my desktop, and I’ll have a stable session until I reboot my computer.

On my laptop, the issue will persist even after reinstalling sddm. I haven’t had the time to dive into this further, but I’m hoping to get it figured out soon.

rocky · February 21, 2026, 3:23pm

This issue reminds me a lot of what I experienced when using LXQt. In my case, I have an NVidia graphics card. The fix was disabling Nouveau and using the proprietary NVidia driver. I’m aware not everyone would want to do that though (guessing you could tweak Nouveau instead).

Worth checking if you also have an NVidia card to narrow it down.

n1ckla · February 21, 2026, 6:26pm

Found a work around. The problem may not be the graphic card, but somehow, the last update introduces a race condition in SDDM login and PAM.

For some reason, X startup exceeded the SystemD or LoginD time out limit that making SDDM gave up and terminate X session while it’s still running. Haven’t found the real culprit yet, but I accidentally found a work around.

For some reason, if in the SDDM login screen you open up a TTY (Ctrl+Alt+F4) (recommend TTY4 cos for some reason, WM and DE is fond of TTY 1-3), login to the TTY, then do some blocking operation, say sleep 300, then back to the 1st TTY SDDM occupy to login to the DE/WM, problem disappears. Race condition resolved (?). WM/DE loads normally, and it’s stable.

For sure, the steps are:

Boot to Login screen
Open up TTY 4-7 (Ctrl+Alt+F4-7)
Login to that TTY
Do sleep 300
Switch back to SDDM (Ctrl+Alt+F1)
Login as usual
DE/WM loads as normal, not thrown back to login screen

This may be a coincidence, but I tried it consistently in my system. Can anyone else verify?

Meanwhile, I undo those tweaks to p11-kit, ssh-agent, but kept KWallet disabled.

If anyone tested this and works, the following may help “automate” this: Make TTY4 autologin, do sleep 300 while we login in SDDM, and as it wakes up, it automatically logout TTY4.

$ sudo mkdir -p /etc/systemd/system/getty@tty4.service.d/

$ sudo tee /etc/systemd/system/getty@tty4.service.d/autologin.conf << EOF
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin ${id -un} --noclear %I \$TERM
EOF

sudo systemctl enable getty@tty4.service
sudo systemctl daemon-reload

Edit ~/.bash_profile, add the following to the bottom:

if [ "$(tty)" = "/dev/tty4" ]; then
    sleep 300
    logout
fi

For the time being, this work for me.

Other avenues/possibilities:

Extending the timeout so sddm-helper doesn’t kill X session:
- in /etc/systemd/system.conf:
```
[Manager]
DefaultTimeoutStopSec=5min
```
- in /etc/systemd/logind.conf:
```
[Login]
UserStopTimeoutSec=5min
```
Some Bus messages do not reach it’s intended destination (maybe)

Hope someone could verify this, and helpful for anyone.

zeroability · February 21, 2026, 8:56pm

Please be aware of the following guidance:

You need to be using the template provided when submitting support requests. You will also need to follow the guidelines in the template before you post a new topic. It includes what release you are using and will help others search for a solution.

If you are using ROME or Cooker, you will probably need to install the DDX for xlibre x11-driver-video-<driver_name>. In the instance of a recent AMD card it would be x11-driver-video-amdgpu. This should keep the session from crashing. This was already answered in another topic in Support.

schappellshow · February 22, 2026, 12:15pm

FYI, I have an AMD GPU, the x11-driver-video-amdgpu package is already installed on my system, and this same reported issue is still happening.

I know that I’m not the OP, but I have searched the forums, and the times I’ve seen this topic pop up since Nov. haven’t been resolved yet.

schappellshow · February 22, 2026, 12:19pm

I just tested this out, and it worked for me. So it looks like, while it’s not a solution to the actual problem, it’s at least a doable workaround.

schappellshow · February 22, 2026, 1:45pm

After some more digging, it looks like this issue is actually a known bug with SDDM 0.21.0. The issue was fixed ~~with an update~~ in PR #2103. It looks like the ROME & Cooker versions of SDDM are the same, so if this issue is happening with SDDM 0.21.0-11 in ROME, then we’re pretty much just waiting for an update to SDDM. Until then, the “open TTY 4-7 & do sleep 300” workaround seems like the best option.

zeroability · February 22, 2026, 2:40pm

It’s probably not related, then.

Did you make a topic already?

system · March 9, 2026, 2:41pm

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.