gldriverquery leaves an inhibitor lock on the system until logout
Hey good evening. I'm not convinced as to close this yet, but I noticed that after resetting and re-installing steam (the entire runtime including the ubuntu runtime), the SDL locks are no longer being set on my system. I wonder if it was an issue with a faulty gldriverquery?
In any case, there have been times where Steam would boot and this problem didn't occur. I'll let you know in a few days and if I don't encounter this issue again, I'll close this.
There was a recent fix for gldriverquery crashing during shutdown. Maybe that has an impact on this? If this lock is negotiated via dbus, shouldn't the setup be smart enough to lift the lock if the process dies?
I'm not sure. In any case, even after a recent reset of the runtime, I have now begun receiving these locks on my system again. 'twas a good day without them, yesterday was.
You can set SDL_VIDEO_ALLOW_SCREENSAVER=1 to stop SDL from disabling the screensaver.
We will add this hint to gldriverquery - it shouldn't disable the screensaver in the first place it's a very short lived process.
We assume this happens because gldriverquery is still crashing for you, either you are running an old build or have some other issue causing this (https://github.com/ValveSoftware/steam-for-linux/issues/11052).
DBus not being resilient to process crashes seems like a shortcoming of the API though. But that's not us.
Note that unrelated to this the Steam client will also prevent the screensaver from kicking in: https://github.com/ValveSoftware/steam-for-linux/issues/5607
Yeah, though the Steam client is actually identifying itself when it places an inhibitor lock on my system. When the Steam client is closed and minimized to tray, I do not have the problem of it trying to inhibit screen lock on my system. My issue is solely with gldriverquery. Is there a way to find version and logs of that process in particular?
Closing this issue in favor of #11052 and because the discussion surrounding it provides decent workarounds to the problem I've been having. Launching Steam with SDL_VIDEO_ALLOW_SCREENSAVER=1 prevents SDL-specific inhibitor locks from being placed on my system which solves this problem for me. While it's possible that gldriverquery might still be crashing for me, it hasn't caused any issues outside of the lock problem that I opened this issue for, so I'll just hope that some update fixes it eventually.
For anyone who might come across this problem in the future, I wrote this script (for KDE) that cleans up any and all dbus inhibitor locks on the system for scenarios like this:
#!/bin/bash
kdialog --warningyesno 'This script will clear all inhibitor locks placed on the system. Are you sure you want to do this?'
if [ $? -eq 0 ]; then
for i in {1..403} ; do echo -n "$i " ; qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement/Inhibit org.freedesktop.PowerManagement.Inhibit.UnInhibit $i ; done
kdialog --msgbox 'Inhibitors have been cleaned up.'
fi
Your system information
This bug is also present in the stable version of the Steam client.
Additional Info
Please describe your issue in as much detail as possible:
One day, after leaving my laptop on without manually locking or putting to sleep, I returned home to notice that it was still powered on, and the monitors (both internal and external) had neither dimmed nor turned off. When I checked the battery widget, I had noticed that there were two inhibitor locks on my system, both from an unknown application.
Note that when an application does not supply its own name and reason, these are the default values that SDL uses.
I went onto KDE Discuss with the thought that KDE itself might be the problem, and also since KDE does not tell me the source application of the inhibitor lock. After some discussion, I was able to write a few bash scripts to run at startup in order to figure out what is placing the inhibitor locks on my system.
The first script below will simply output the results of dbus-monitor to a file in the downloads folder, acting like a log file:
The second script takes each line from dbus-monitor and uses some weird regex to extract the sender string so it can be parsed to find the sender information. From the sender information, I then find the command line used to spawn the process ID from the sender information. All lines generated from the script are then outputted to another text file acting like a log:
Here is the resulting “log” file of the second script:
So from what it looks like,
gldriverqueryis placing an SDL inhibitor lock without ever asking it to uninhibit the system. So even after the connection is lost whengldriverqueryis closed, the lock is never lifted. I think that this is very bad.Steps for reproducing this issue:
Here is the thread on KDE Discuss I created where I initially asked for help regarding this bug. Note that due to the nature of it, I was unaware that this was a Steam bug at the time, and did not believe Steam had a part in it.
https://discuss.kde.org/t/my-sdl-application-is-inhibiting-screen-lock/20273