Bug 1214104

Summary:	Occasionally screen cannot be unlocked
Product:	[openSUSE] openSUSE Distribution	Reporter:	Alexander Osthof <aosthof>
Component:	KDE Workspace (Plasma)	Assignee:	E-Mail List <opensuse-kde-bugs>
Status:	NEW ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	aosthof, fvogt
Version:	Leap 15.5
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	journalctl output journalctl output 2023-09-11 loginctl session-status output

Description Alexander Osthof 2023-08-09 07:59:54 UTC

User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Build Identifier: 

Sometimes when I lock my screen I cannot unlock it anymore. When trying to do so I get asked for my password and then a 'unlock' button appears. When I click this button nothing happens.

It's particularly annoying if you have unsaved work but you can't get there anymore without restarting X or reboot the system.

In previous version of openSUSE Leap the 'unlock' button was not there at all and the screen was unlocked directly after I've entered my password.

Reproducible: Sometimes

Steps to Reproduce:
I cannot provide a reliable way to reproduce this issue but when this issue happens it happens after the screen was locked over night (so for a couple of hours).


Expected Results:  
From my point of view the 'unlock' button is superfluous and the screen should unlock directly after the user password is entered.

Comment 1 Fabian Vogt 2023-08-09 08:03:47 UTC

You can use "loginctl unlock" to work around this when it occurs.

Anything relevant in the journal?

Comment 2 Alexander Osthof 2023-08-10 12:17:59 UTC

Thanks for the workaround hint, Fabian! I'll have a look at the journal next time this issue occurs.

Comment 3 Alexander Osthof 2023-08-21 07:44:55 UTC

As expected, after a longer period of time the screen couldn't be unlocked anymore. I've saved the journalctl.log and unlocked the screen manually with "loginctl unlock-session $SESSION_ID".

Comment 4 Alexander Osthof 2023-08-21 07:47:17 UTC

Created attachment 868901 [details]
journalctl output

This journalctl output contains the log from trying to unlock the graphical screen (which failed) until the login on tty1 by root to workaround the issue by manually unlocking the screen with "loginctl unlock-session $SESSION_ID".

Comment 5 Fabian Vogt 2023-08-21 08:47:28 UTC

I see some screen events, maybe that's related somehow. If all the greeter instances disappear and at some point reappear, it might get confused.

The screen with the "Unlock" button appears if PAM didn't ask for a password before triggering the "succeeded" handler, but apparently something reset the success state at some point, either by starting a new attempt in parallel or calling the "failed" handler. This causes the "Greeter tried to quit without being unlocked" log message.

Please set the log level of the "KScreenLocker (greeter)" category to "full debugging" using kdebugsettings. That should show which one of those scenarios happens.

Comment 6 Alexander Osthof 2023-08-22 08:18:15 UTC

I've set the log level to "full debugging" now and will provide the log next time the issue occurs.

Comment 7 Alexander Osthof 2023-09-11 07:13:13 UTC

Happened this morning again, I'll attach the output of this morning's journalctl and the output of `loginctl session-status`.

Comment 8 Alexander Osthof 2023-09-11 07:13:45 UTC

Created attachment 869410 [details]
journalctl output 2023-09-11

Comment 9 Alexander Osthof 2023-09-11 07:14:17 UTC

Created attachment 869412 [details]
loginctl session-status output