Bugzilla – Bug 1214104
Occasionally screen cannot be unlocked
Last modified: 2023-09-11 07:14:17 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.
You can use "loginctl unlock" to work around this when it occurs. Anything relevant in the journal?
Thanks for the workaround hint, Fabian! I'll have a look at the journal next time this issue occurs.
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".
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".
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.
I've set the log level to "full debugging" now and will provide the log next time the issue occurs.
Happened this morning again, I'll attach the output of this morning's journalctl and the output of `loginctl session-status`.
Created attachment 869410 [details] journalctl output 2023-09-11
Created attachment 869412 [details] loginctl session-status output