With the following config, I can't unlock the screen (after locking it by waiting until autolock happens), as the widget to enter the password is missing (just the background picture is shown) ~/.kde4/share/config/kscreensaverrc: [ScreenSaver] Enabled=true LegacySaverEnabled=false Lock=false LockGrace=60000 PlasmaEnabled=false Timeout=60 After killing /usr/lib/kde4/libexec/kscreenlocker_greet, the widgets reappear and I can unlock the desktop (it looks like a new kscreenlocker_greet process is started with the argument "--immediateLock"). This can be reproduced with a new user.
I have similar symptoms using OpenSuse 12.3 packages for KDE 4.11.4 installed. Under KDE System Settings / Power Management / AC Power, the system is set to "Sleep" after X minutes of inactivity. It is also set to sleep on lid close. If I close the lid, upon opening it again it comes out of sleep normally, and kscreenlocker_greet shows with a dialog box to accept password. This works correctly. If I manually lock the screen (ctrl alt L) the dialog is shown and I can log in correctly. However, If the inactivity time triggers a sleep, (with the laptop lid open), and I wake the computer by pressing power button, it properly resumes, from sleep, but the session is locked, the background screen is showing, but kscreenlocker_greet is NOT showing at all, and therefore, there is no dialog into which I can key password. I am locked out of the session. If I open a shell, or ssh into the system and kill kscreenlocker_greet, it immediately relaunches and shows its dialog screen and allows me to enter the password, and operates normally. This occurs for me only when the Suspend Session time triggers a Sleep. Advanced settings on the power management screen show Lock on Resume checked as well as Never prevent an action on lid close.
Happens to me too after some patch was installed. I'm running OpenSuSE 13.1. First everything was fine, but (i guess) some patch was installed, the widget doesn't appear. Didn't try all the flavors John mentioned, but only the inactivity timer. Also didn't try to kill the kscreenlocker_greet process (yet) I'm running KDE4 4.11
killing the kscreenlocker_greet process works for me, i get a fresh window where i can enter my password. $ rpm -q --changelog kdebase4-workspace-4.11.4-89.26.x86_64 * Sun Dec 01 2013 tittiatcoke@gmail.com - Update to 4.11.4 * KDE 4.11.4 maintenance release * See http://www.kde.org/announcements/announce-4.11.4.php - Drop upstreamed patches: * 0001-introduce-a-locked-property-for-the-qml-lock-screen.patch * adjust-to-upower-0.99.patch * Fri Nov 22 2013 hrvoje.senjan@gmail.com - Disable previous patch, due to bad side-effects (kde#327947) * Fri Nov 22 2013 hrvoje.senjan@gmail.com - Added 0001-introduce-a-locked-property-for-the-qml-lock-screen.patch from upstream, for resolving potential security risk where the screenlocker would show it's locked, but infact isn't (kde#315442, bnc#802959) * Sun Nov 10 2013 hrvoje.senjan@gmail.com - Due to upstream chages in kde-workspace release policy (only 4.11.x bugfixes) require kdeartwork4, kdebase4-wallpaper-default and python-kde4 equal or greater than kde-workspace version - Added adjust-to-upower-0.99.patch which ports Powerdevil to new UPower API/ABI/DBus interface * Sat Nov 02 2013 tittiatcoke@gmail.com - Update to 4.11.3 * KDE 4.11.3 bugfix release * See http://www.kde.org/announcements/announce-4.11.3.php - Drop helper_actions_syspath.patch, and create rpmlintrc file during build phase for older openSUSE versions ..... I guess the error was introduced on Sun Dec 01 2013 when yast updated it to version 4.11.4 (from 4.11.3)
Using opensuse 13.1 I had the same issue after the kde update to version 4.11.4. In "Power Managment" I had the "Suspend Session" enable with the option "Lock Screen". After disabling the option last weekend and reenabling it on Monday the password box appears again.
Same error in Kubuntu 13.10 on a lenovo laptop.
Same on Kubuntu 13.10 after update to KDE 4.11.5. This happens to me after waking from suspend. It only happens when suspend automatically kicked in after 30 minutes (my setting). If I manually suspend the system and wake it up the unlock dialog appareas correctly. This might be useful as well: http://forum.kde.org/viewtopic.php?f=66&t=119282&start=15#p301773
Recent update from openSuSE to KDE 4.11.6 didn't solve this. I'm running: $ rpm -q --whatprovides /usr/lib64/kde4/libexec/kscreenlocker_greet kdebase4-workspace-4.11.6-107.1.x86_64 and kde4-kgreeter-plugins-4.11.6-107.1.x86_64
Seems to be the same as https://bugs.kde.org/show_bug.cgi?id=327947, especially comment#3 and onwards.
See opensuse bug 864305, there is a pre-release fix for this.
*** Bug 332203 has been marked as a duplicate of this bug. ***
Git commit 026bd64b2f681b0725a2136866f8cbb8e5adb60e by Wolfgang Bauer. Committed on 24/04/2014 at 22:11. Pushed by wbauer into branch 'KDE/4.11'. Force the screen locker's greeter to show the password input field in case of immediateLock If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Related: bug 327947 FIXED-IN: 4.11.9 REVIEW: 117091 M +6 -0 ksmserver/screenlocker/greeter/greeterapp.cpp M +1 -0 ksmserver/screenlocker/greeter/greeterapp.h M +18 -0 ksmserver/screenlocker/greeter/main.cpp M +5 -0 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/kde-workspace/026bd64b2f681b0725a2136866f8cbb8e5adb60e
Git commit 185dfbd70b88e60023742b946473c0eca91b344a by Wolfgang Bauer. Committed on 25/04/2014 at 20:43. Pushed by wbauer into branch 'master'. Force the screen locker's greeter to show the password input field in case of immediateLock If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Related: bug 327947 REVIEW: 117091 M +6 -0 ksmserver/screenlocker/greeter/greeterapp.cpp M +1 -0 ksmserver/screenlocker/greeter/greeterapp.h M +18 -0 ksmserver/screenlocker/greeter/main.cpp M +5 -0 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/plasma-workspace/185dfbd70b88e60023742b946473c0eca91b344a
It is still happening on 4.11.5 (Kubuntu), identical symptoms (not sure if this is appropriate to report it here)... I can log in only by killing the /usr/lib/kde4/libexec/kscreenlocker_greet process, that forces the login prompt to show up.
(In reply to comment #13) > It is still happening on 4.11.5 (Kubuntu), identical symptoms (not sure if > this is appropriate to report it here)... Yes, of course. 4.11.5 is from January, I commited the fix in April. It should be fixed in kde-workspace 4.11.9. Please file a bug report with your distribution to get updated packages (point them to this bug report).
Hi, i think the issue is not fixed or has reappeared recently. I had the same issue on KDE Neon 18.04 KDE 5.17. The symptoms are the same as mentioned early : when the PC woke up, the login screen appears but there is no input to type password, neither the time or date. I have the issue only on the work computer which is a Dell computer............... I am not surprised at all (Dell computer are a nightmare on Linux...), but the bug is quite annoying.... Thanks
(In reply to Arnaud Frézet from comment #15) > i think the issue is not fixed or has reappeared recently. I had the same > issue on KDE Neon 18.04 KDE 5.17. Please file a new bug report then. This one was about KDE4 and has been fixed years ago. The code is not even close to being similar anymore.
Thanks, a new bug have been filled : https://bugs.kde.org/show_bug.cgi?id=413387