

Thanks! This is what I’m getting here. If I understand this correctly, this is a list of POSSIBLE inhibitors…not which one was triggered last time blocking the actual suspension right?
WHO UID USER PID COMM WHAT WHY >
Libvirt 0 root 77709 libvirtd shutdown Virtual machines need to be saved >
ModemManager 0 root 1183 ModemManager sleep ModemManager needs to reset devices >
NetworkManager 0 root 1087 NetworkManager sleep NetworkManager needs to turn off networks >
UPower 0 root 1896 upowerd sleep Pause device polling >
PowerDevil 1000 timonoj 2165 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power events >
Screen Locker 1000 timonoj 1878 kwin_wayland sleep Ensuring that the screen gets locked before going to sleep>
6 inhibitors listed.
lines 1-9/9 (END)
Having a second thought about this, it looks like Screen Locker might be the culprit. But I’m not completely sure. I really could see the desktop wasn’t even locked after a whole night. So maybe it failed to trigger? How can I look at…what’s inhibiting the screen from locking, now? Just like suspension, it works when manually triggered with Meta key + L.


Sure, I could suspect it…but how can I try to troubleshoot it? Is there a way to see what blocks the desktop from locking the screen?