Created attachment 176180 [details] Authentication dialog when trying to suspend SUMMARY After waking up the PC from a suspended state, and after entering the password on the lock screen, FREQUENTLY it will cause the current session to be in state 'closing'. The output of 'loginctl' then becomes: ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 closing no 3 983 sddm seat0 tty2 online no``` Compare that with the normal state, prior to the suspend and before the bug happens: ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 active no``` The consequence(s) of this, when it happens is that: 1. I can't suspend the PC again without authentication (see attached screenshot) 2. Plugging in USB devices requires authentication (similar to 1. ) 3. Rebooting or shutting down makes the system hang indefinitely STEPS TO REPRODUCE 1. Suspend PC 2. Wake the PC up after a while 3. Unlock the lock screen by password 4. Run 'logintctl' in terminal OBSERVED RESULT I need to authenticate for suspending PC and plugging in USB devices. System hangs on normal reboot and shutdown. To reboot/shutdown when the bug happens, I need to use 'sudo', e.g. 'sudo systemctl shutdown'. EXPECTED RESULT System should behave as it did prior to suspend, with no authentication required. SOFTWARE/OS VERSIONS Operating System: Solus 4.6 KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.7.3 Kernel Version: 6.11.10-310.current (64-bit) Graphics Platform: Wayland Processors: 12 × 13th Gen Intel® Core™ i7-1355U Memory: 62,5 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: Intel ADDITIONAL INFORMATION
It just happened again, after the very first suspend and a wakeup only a couple of minutes later. But I tried something new. Instead of entering my password I went to tty1 (Ctrl+Alt+F1), and my session was still there. Loginctl showed: ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 active no c1 983 sddm seat0 tty3 online no``` Note that my session state says 'active'. Before I could kill the sddm session with `loginctl terminate-session c1` the lock screen appeared again, about 30 seconds after switching to tt1. I returned to tty1 again without logging in, and immediately did `loginctl` again and got: ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 closing no c1 983 sddm seat0 tty3 online no c2 983 sddm seat0 tty2 online no``` So the second lock screen appears to have been shown on tty2, and my session state changed to 'closing'.
Happened another two times since my last comment yesterday. Today was so bad I couldn't login at all, I just got a black screen after entering my password on the lock screen, on all ttys that i tried. On one tty i managed to login from the cmd, so I dumped the `loginctl` info into a file from there: ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 closing no 17 1000 rocnir seat0 tty4 closing no 19 1000 rocnir seat0 tty7 closing no 21 1000 rocnir seat0 tty7 closing no 23 1000 rocnir seat0 tty4 active no 24 1000 rocnir seat0 tty7 closing no 26 1000 rocnir seat0 tty7 closing no c14 983 sddm seat0 tty1 online no``` It was a complete mess. I was forced to do a `sudo systemctl reboot` to recover.
I have discovered two more details. 1. As the 'loginctl' output shows, the lockscreen is always presented on tty2. HOWEVER, by going to tty1 (Ctrl+Alt+F1) I am back in my session and can bypass the lockscreen without having to enter the password. My session state then is still 'active', while 'sddm' user state is 'online'. But the fact that I'm presented with a lockscreen that I can bypass by going to another tty is clearly a severe bug! 2. After bypassing the lockscreen, if I then do a copy-operation (Ctrl+C or Ctrl+Shift+C), I am then presented with another lockscreen on tty3. I can again go to tty1, but my session has then changed to 'closing', as I have reported earlier. Surely I'm not the only one with this bug. My updated KDE/Plasma versions: Operating System: Solus 4.6 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.1 Kernel Version: 6.11.10-310.current (64-bit)
Unfortunately you might be; I haven't heard of anyone else encountering this, and I can't reproduce it myself on current git master, built from source on top of Fedora KDE 41. Does the issue reproduce for you in a new clean user account?
So it just happened again as I woke up the computer to reply (it was the first suspend + wake up today after a fresh boot this morning). But instead of going straight to tty1 I entered the password (on tty2 I presume). Only got a black screen. So I went to tty1 but got a spinning wheel animation, as if it was loading/restarting the Plasma and/or the session. Finally got to my session, so I checked 'loginctl': ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 active no 4 1000 rocnir seat0 tty4 closing no c2 983 sddm seat0 tty3 online no``` As I hit 'Ctrl+Shift+C' to copy the above output I instantly got another lockscreen. I returned to tty1 and now 'loginctl' says: ```SESSION UID USER SEAT TTY STATE IDLE SINCE 1 1000 rocnir seat0 tty1 closing no 4 1000 rocnir seat0 tty4 closing no c2 983 sddm seat0 tty3 online no c3 983 sddm seat0 tty2 online no``` I will create a new admin user and try, and report back.
Created attachment 176564 [details] Dialog after wakeup The dialog presented after bypassing the lockscreen by going to tty1.
So I rebooted with my regular user and suspended and woke up the PC after about 15 seconds. I did this several times, with no problem. I then suspended and waited about 5 min before waking up, and got the reported bug. When I returned to tty1, without entering the password, I got the dialog in my previous comment. (I did not open any programs while I did the tests). I have seen that dialog a few times, but not always. Maybe that's where the problems starts, since it seems to ask me for authentication prior to the suspend? Next, I will create a new admin user and try to reproduce.
Preliminary result is that a new user account does not have this issue, I have not been encountered the bug so far after multiple suspend + wake ups. The only thing I can think of is that I installed 'dotool' on my main account: https://git.sr.ht/~geb/dotool as per the instructions, which does something with 'udevadm'. However I don't understand what that does and if it could hypothetically cause this. I also installed dotool on the new account but it didn't seem to make a difference (so far). Assuming it's some specific setup/process running on my main account that could cause this, any suggestions are welcome. Whatever the issue is I don't think it's the correct behavior of the lock screen.
The same bug occurred in the test account as well just a short while ago: got a lock screen despite having disabled it. Entered the password and switched user (to my regular account), which led to a bunch of issues: - pressing Ctrl+C got me the lock screen again. - after entering my password I was back to the test user account. - I tried to switch back (switch user) to my regular account, but my main account didn't even show up, only the test account was shown. - tried logging out instead from my test account but it literally did nothing at all, completely dead. It kept me logged in. - couldn't switch to any ttys. Was forced to reboot from the terminal. Needless to say it's completely unsustainable for a work (+ personal use) PC. I will switch to another DE and won't report here any more. Please close all the reported bugs.
Sorry you had a bad experience. Unfortunately since nobody else has reported this issue and I can't reproduce it, you moving to another DE will make it impossible for us to eventually identify and fix the issue (if indeed it's a code issue on our side). Closing. I hope you have a better experience with whatever you move to.