Some years ago, I did something to inhibit the KDE screensaver, because I was using xscreensaver instead. Evidently I didn’t do it through systemsettings, as it’s not configured to be disabled there, or indeed in ~/.config/kscreenlockerrc (possibly that option wasn’t available at the time).
My best guess is that I did this through qdbus, but the problem is that to uninhibit it there I need to know the cookie I used in the first place.
Hence my question as to how I can uninhibit it without knowing the cookie. I’m guessing that somewhere, there’s a dbus configuration file I might be able to edit, but haven’t been able to work out what or where that is.
You say you don’t recall but might it be possible you created a service at some point to run kde-inhibit? Specifically, the Inhibit Screen Saver functionality…
I say service because I’m uncertain whether kde-inhibit actually survives a reboot normally.
WHO UID USER PID COMM WHAT WHY MODE
PowerDevil 1000 tony 782782 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power events block
1 inhibitors listed.
Which suggests this isn’t the culprit.
In fact, I’m pretty sure I will have over-ridden it in favour of xscreensaver long before systemd came along.
Nothing I can find in any scripts or service files. Though I’m pretty sure I will have inhibited this in favour of xscreensaver before systemd even came along.
This is certainly looking hopeful. Curious that although it didn’t work with one running of those commands, there were still more such cookies set. I’m currently running a script to keep doing the uninhibit as long as a cookie is returned and there are [Edit] tenshundreds of thousands of them, so it may take a while. I’ll know if it’s worked when that finishes…
Strange that I still can’t see any file on my root partition that’s been updated while I’ve been deleting these cookies. It’s almost as if dbus doesn’t store things in files, which seems improbable. Unless it only flushes to a file occasionally.
