GNOME Bugzilla – Bug 685499
session manager does not correctly release system inhibitors
Last modified: 2012-10-23 10:10:20 UTC
It seems that when gnome-session 3.6.0 forwards an inhibitor to systemd, it *sometimes* (not always) forgets to release it afterwards. In the example below, it holds five systemd inhibitors despite no session inhibitors being present: $ gdbus call --system -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors ([('shutdown:sleep', 'grawity', 'user session inhibited', 'block', uint32 1000, uint32 526918), ('shutdown:sleep', 'grawity', 'user session inhibited', 'block', 1000, 526918), ('shutdown:sleep', 'grawity', 'user session inhibited', 'block', 1000, 526918), ('shutdown:sleep', 'grawity', 'user session inhibited', 'block', 1000, 526918), ('shutdown:sleep', 'grawity', 'user session inhibited', 'block', 1000, 526918)],) $ pgrep -lf gnome-session 526918 /usr/bin/gnome-session $ gdbus call --session -d org.gnome.SessionManager -o /org/gnome/SessionManager -m org.gnome.SessionManager.GetInhibitors (@ao [],) $ ls -l /proc/526918/fd/2? lrwx------ 1 grawity grawity 64 Oct 4 14:40 20 -> anon_inode:[eventfd] l-wx------ 1 grawity grawity 64 Oct 4 14:55 21 -> /run/systemd/inhibit/124.ref| l-wx------ 1 grawity grawity 64 Oct 4 14:40 22 -> /run/systemd/inhibit/119.ref| l-wx------ 1 grawity grawity 64 Oct 4 14:55 24 -> /run/systemd/inhibit/129.ref| l-wx------ 1 grawity grawity 64 Oct 4 14:55 25 -> /run/systemd/inhibit/143.ref| l-wx------ 1 grawity grawity 64 Oct 4 14:55 26 -> /run/systemd/inhibit/164.ref|
how did these inhibitors get taken in the first place ? what application ? how did you drop them ?
It seems that one way of reproducing this bug is to take a suspend inhibitor and release it immediately. But none of the programs I use do this... I think most of the inhibitors were taken by my `gnome-inhibit` [1] script (for example, `gnome-inhibit --what=suspend youtube-dl <url>`); the script runs a program, and releases the inhibitor by calling org.gnome.SessionManager.Uninhibit() when it exits. A few inhibitors are taken by Transmission-GTK. It takes a suspend inhibitor when a download is active, and releases it when the download activity stops. I'm not sure if the programs themselves are problematic, since *session* inhibitors are released correctly. Only gnome-session sometimes doesn't release the associated systemd inhibitor when the last session inhibitor is gone. [1]: https://github.com/grawity/code/blob/master/x11/gnome-inhibit
(In reply to comment #2) > It seems that one way of reproducing this bug is to take a suspend inhibitor > and release it immediately. But none of the programs I use do this... Thats a useful hint, anyway. One scenario we currently don't handle is if the session inhibitor is removed before our async call to obtain a system inhibitor returns.
Created attachment 226907 [details] [review] a patch Here is a patch that may help. It should handle the case where the session inhibitor has already be removed again by the time the systemd dbus call returns.
Review of attachment 226907 [details] [review]: ::: gnome-session/gsm-systemd.c @@ +90,2 @@ } + drop_system_inhibitor (systemd); probably need to initialize inhibit_fd to -1 at init time if you're going to check for -1 at finalize time, otherwise we'll be closing STDIN in some cases, i think.
Good catch. Pushed with that fix