SUMMARY Come to work in the morning and I can't log in to KDE (unresponsive). /var/log/messages shows unsuccessful NFS accesses overnight (folder for lockscreen images is on this export). NFS is now restored. It is a desktop system, hibernate or sleep are not involved. STEPS TO REPRODUCE 1. Set lockscreen image folder to remote mounted folder of images. 2. Let lockscreen lock (works most of the time, weeks at a time). OBSERVED RESULT Lockscreen freezes for good if nfs share is offline when changing images. Note: this has never happened with the desktop background which also uses the same remote folder. EXPECTED RESULT Lockscreen should fail gracefully if image/folder/share is unavailable. SOFTWARE/OS VERSIONS Windows: na macOS: na (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Gentoo/Calculate KDE Plasma Version: Plasma 6.1.5 KDE Frameworks Version: 6.5 Qt Version: 6.7.2 ADDITIONAL INFORMATION My best guess is that the screenlocker tries to open the file and just waits forever until the system call returns. Which it never does, even once the network share comes back. It should not trust any folder to actually exist or be accessible, instead it should use a safe method of determining whether the next image exists and is readable, and if it's not fail gracefully. Note that some of the bugs in the "related bugs" list seem to have a similar character of failing sometimes catastophically when folders on remote shares aren't accessible. This doesn't seem like the world's most critical bug, but it does freeze all of KDE and force a restart. Nothing should ever have that power.
Note: remote mount is over WAN (wireguard + nfs over internet to another site) with ping of ~0.3s. Shouldn't make a difference, right?
We should definitely fix this, but setting the lockscreen background to a transient image on an NFS share is also probably not advisable.
Options include: - Cache the specified image locally so this can't happen - When we can't find the configured image, fall back to the default one
(In reply to Nate Graham from comment #2) > We should definitely fix this, but setting the lockscreen background to a > transient image on an NFS share is also probably not advisable. Sure. Agreed. Many thanks! I like both of the proposed solutions. The computer in question is a client only, and I don't actually care if I have to reboot it, but would rather not. It runs the big monitor in the room where I meet with people, and I hate to have my visitors watch me reboot just to have a meeting (What kind of mac is that, they ask). Having it cycle through the server images it is a kind of digital poster when I'm not using it. For sure not everybody's use case, but we have millions of KDE users. I have thought of other workarounds a data center would do, but I'm just one guy. I had the problem more acutely with Dolphin, which would poll the remote volume a lot if you had it in the sidebar (and then freeze). They seem to have fixed that. Now the worst it does is like if you pull the USB out with the folder open, just puts up a warning and keeps working. Thanks again!
Created attachment 174724 [details] journalctl -b -1 | grep 'hibernate\|amd\|gpu' OS: Manjaro Linux x86_64 Host: 82RN IdeaPad 3 15ABA7 Kernel: 6.10.13-3-MANJARO Shell: bash 5.2.37 CPU: AMD Ryzen 7 5825U with Radeon Graphics (16) @ 4.546GHz GPU: AMD ATI 04:00.0 Barcelo Memory: 2837MiB / 13820MiB Since the update to plasma 6 the system is not starting with a log in screen after wake up from hibernate. As you can see in the log hibernate works fine. There is no mouse or keyboard. It's not possible to switch to an other tty to start sddm manually. The system is frozen. The only solution is a hard reset. I've update the bios to the last recent version.... no solution. The issue is still there. Randomize it works but in 99% of the cases the restart from hibernate ends with a hard reset. That has nothing to do with "stable" version. The machine should go into hibernate when the lid get closed. But that isn't possible anymore since the update to version 6.*
unimatrixzero, that's unrelated. Please open a new bug report for it. Thanks!