Created attachment 101846 [details] The tarball containing the ebuild for currently compiled kscreenlocker mentioned in the bugreport This results in frozen process-output (of kscreenlocker_greet) at TTY7 where X session is running. Currently logged in user(s) cannot reach their sessions and SDDM has to be killed to re-initiate login(s) from TTY7. kscreenlocker: DIST kscreenlocker-5.8.2.tar.xz 108036 SHA256 e17abef1b648a6ed77d5646d3378a44273ddd9d4a06c2747fbbf2a4f0a145e55 SHA512 75c61ae4187808382ebf4db4d55c056445163ec85edfc202a84c835b6259f09d2e11ed3d68c6f4afbcdc9bf35c8b3e20efe00433e992a0f08ccfd01d2bd7d7e0 WHIRLPOOL f2798a8147c6c1d0861accbef8091adb9056cfdea6e3417f31d65dfec6fe4bd72a78cbdd4443b8ee7b244837bc5ed4aec717e92de4c30f0d43af0d376b6f0b7d KDE: 5.27.0 Qt: 5.6.2 plasmashell 5.8.2
is kscreenlocker_greet still running? If yes can you try to gdb in and get a backtrace
(In reply to Martin Gräßlin from comment #1) > is kscreenlocker_greet still running? If yes can you try to gdb in and get a > backtrace I could not find any process with kscreenlocker in the name, I tried to find it using 'ps aux | grep locker', so I'd say that's a no. It looks like the process has frozen and died, clock had stopped at 04:43:23 this morning when I returned to desktop around 08:00. This behaviour of kscreenlocker has been confirmed by another freenode user in the gentoo community, and incident has occured twice for me.
I think there is a bigger problem than the freezing of the locker. As the process is no longer running the screen should not show the window any more. It must be removed if the process dies. And that's the job of the X server. If kscreenlocker_greet crashes ksmserver will restart it. So that there is always a locker. If the restart fails for four times the lock screen architecture goes into emergency mode. The lock screen is replaced by a black screen with a message on how to unlock the screen with loginctl. Given that we should either have the process of the warning message. As both is not the case I fear the problem is deeper in the stack. If it happens the next time please try to get some more information about the system state. Check dmesg for error message (e.g. reported coredumps, hung gpu, etc). Check /var/log/Xorg.0.log for errors. Check top for whether a process is running amok. In case you are using logind you can also try to unlock the session with: loginctl unlock-sessions
(In reply to Martin Gräßlin from comment #3) > I think there is a bigger problem than the freezing of the locker. > > As the process is no longer running the screen should not show the window > any more. It must be removed if the process dies. And that's the job of the > X server. > > If kscreenlocker_greet crashes ksmserver will restart it. So that there is > always a locker. If the restart fails for four times the lock screen > architecture goes into emergency mode. The lock screen is replaced by a > black screen with a message on how to unlock the screen with loginctl. > > Given that we should either have the process of the warning message. As both > is not the case I fear the problem is deeper in the stack. > > If it happens the next time please try to get some more information about > the system state. Check dmesg for error message (e.g. reported coredumps, > hung gpu, etc). Check /var/log/Xorg.0.log for errors. Check top for whether > a process is running amok. > > In case you are using logind you can also try to unlock the session with: > loginctl unlock-sessions I am not using systemd, my gentoo runs on openrc, so no loginctl is present in my setup. When programs crash I usually see an entry in /var/log/messages (syslog) and get a core file containing the crashdump, I did not find either for kscreenlocker_greet.
Thanks for the report Arvid. I leave my PC on at night as well quite often and I've never come back to it with the clock frozen or the process gone. Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!