dbus idle inhibitors leak

[Nemo157]

I've noticed a few times some games will increase the inhibit count but never decrease it again.

Checking the spec I noticed this part:

Inhibition will stop when the UnInhibit method is called, or the application disconnects from the D-Bus session bus (which usually happens upon exit).

Afaict from a skim of the code the latter part is not implemented, I don't see anything that resembles watching for disconnects.

Can be tested via:

> busctl --user call org.freedesktop.ScreenSaver /org/freedesktop/ScreenSaver org.freedesktop.ScreenSaver Inhibit ss 'test' 'foobar'
u 1412

and you'll see the lock count just increase in the logs:

[LOG] ScreenSaver inhibit: true dbus message from test with content foobar
[LOG] Inhibit locks: 10
[LOG] Cookie 1411 sent
[LOG] ScreenSaver inhibit: true dbus message from test with content foobar
[LOG] Inhibit locks: 11
[LOG] Cookie 1412 sent

[Nymnz]

I am also having this issue, I don't know what is filling up the inhibitors but after a while they are always above 1. I hope someone can look into fixing this, would really like this to work for the sake of my oled monitor.

[andresilva]

I don't think this is a problem with hypridle but with applications not properly releasing inhibit requests. Steam is one such application, it sends an inhibit dbus message on startup and doesn't release it on shutdown (I have checked this with dbus-monitor). My workaround was to set RuntimeMaxSec=3h in the hypridle service definition, this makes sure that hypridle is restarted every 3 hours and gets rid of any stray locks.

[Nemo157]

it sends an inhibit dbus message on startup and doesn't release it on shutdown

The quoted part of the specification says this is not necessary, the inhibition should be implicitly released on shutdown.

[andresilva]

You're right, I should have read the issue description more carefully.