Bug 458169 - kscreenlocker causes SDDM not able to reuse sessions
Summary: kscreenlocker causes SDDM not able to reuse sessions
Status: RESOLVED DOWNSTREAM
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: 5.24.6
Platform: Manjaro Linux
: VHI critical
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: regression
: 458193 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-08-22 12:45 UTC by klarnorbert
Modified: 2022-09-14 15:18 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description klarnorbert 2022-08-22 12:45:33 UTC 
SUMMARY

When I switch users using kscreenlocker, it creates a new session, which causing SDDM not able to reuse the previous session for the same user, and giving black screen with cursor.


STEPS TO REPRODUCE
1.  Press switch user on kscreenlocker
2. Create new session
3. Log back in the same account with SDDM
4. Black screen with cursor

OBSERVED RESULT

Black screen with cursor

EXPECTED RESULT

Log back into the first created session

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.15.60-1-MANJARO
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Comment 1 Nate Graham 2022-08-23 06:12:00 UTC 
Can confirm with current git master. This requires a hard reboot to recover from and could lose user data; setting priority appropriately.

May be an SDDM bug with ignoring ReuseSession=true, but needs investigation.
Comment 2 Nate Graham 2022-08-23 13:23:44 UTC 
*** Bug 458193 has been marked as a duplicate of this bug. ***
Comment 3 ratijas 2022-09-05 12:48:19 UTC 
I can confirm that SDDM/KScreenLocker session management is a buggy moor. For example, I can't switch sessions away from a passwordless user (created for testing) back to main account. Or sometimes I do get a black screen with a cursor while switching back and forth.

But it does require a hard reboot: usually things are pretty fixable "simply" by manually navigating to the correct session with Ctrl+Alt+F<N> (where F<N> is F1, F2, ..., F7, F8 etc). Of course regular users don't need to know that, and things should just work. But I'm just posting it here as a workaround for those who find this thread before the bug is fixed.
Comment 4 fhgnne 2022-09-08 20:15:59 UTC 
@ratijas

when having logged in a second time with the same user, BOTH logins are crap - I switched with Ctrl+Alt+F1 and F2 back and forth and none of the screens contained something that was still useful to work with. Ctrl+Alt+F3 => plain console login => sudo reboot required for recovery.
Comment 5 Aleix Pol 2022-09-14 15:11:22 UTC 
This is a bug in SDDM development branch but not in the (aging) last SDDM release.

I'm not sure we should be taking this with such high priority.

I'll be looking into fixing it in SDDM because it needs to but know that switching to last SDDM release fixes it.
Comment 6 Aleix Pol 2022-09-14 15:18:15 UTC 
https://github.com/sddm/sddm/issues/1588