GNOME Bugzilla – Bug 721605
Delaying in shutdown and sleep caused by unintentionally-taken inhibitor with telepathy-mission-control 5.15.1+
Last modified: 2014-01-23 02:10:39 UTC
From version 5.15.1, telepathy introduced a systemd inhibitor to delay the shutdown or sleep when there is an IM client, enabling it to disconnet (See https://bugs.freedesktop.org/show_bug.cgi?id=68758). However, this bugfix seems to cause problems in gnome-shell and gdm since they always take this inhibitor and never releases as if there is always an IM client. For the user who used the newest version of telepathy-mission-control, shutdown will never happen until the inhibitor timed out, causing a 5-second delay between hitting the shutdown button and the real shutdown. I discovered the problem about one month ago after a system upgrade. And recently I looked into the problem and found the problematic inhibitor by using systemd-inhibit --list. Who: Telepathy (UID 1000/dingbur, PID 679/mission-control) What: shutdown:sleep Why: Disconnecting IM accounts before suspend/shutdown... Mode: delay This inhibitor is taken when gdm or gnome-shell starts. I downgraded the telepathy-mission-control to 5.14.1 (a version before the inhibitor was introduced), the inhibitor disappears and the problem was eliminated. Though I do not know very much of the code of GNOME Shell and gdm. I guess the change in telepathy-mission-control causes somewhere of the GNOME Shell and gdm to get the inhibitor unintentionally since gnome-shell depends on mission-control to function. Although this problem is not very serious, the delay in shutdown can cause unpleasant user experience (it doubles shutdown time on my machine). My system: Arch Linux x86_64 with gnome-shell 3.10.2.1 and gdm 3.10.0.1
Why does telepathy do that? If you shutdown without disconnecting the connection will timeout anyway. This is kind of a pointless thing to do.
Because timeout takes time, and meanwhile you still appear as online.
I'm also experiencing the exact same problem. The system instantly shutsdown/sleeps if I kill mission-control right before shutting down/sleep. Source thread of the submitter: https://bbs.archlinux.org/viewtopic.php?pid=1367720#p1367720
(In reply to comment #1) > Why does telepathy do that? If you shutdown without disconnecting the > connection will timeout anyway. This is kind of a pointless thing to do. I think the delay lock is for IM clients. Maybe in the telepathy developers' points of view, if there exists an IM connected client, the delay lock will be taken to do some work (such as sending disconnect message) in case of shutting down. If all IM clients exits or got disconnected, the lock will be released. BUT THE PROBLEM IS, gnome-shell seems to get the delay lock (by using mission-control) upon start even if we don't use ANY IM client, and the lock is never released. So shutdown will be always delayed.
A (not so pretty) workaround is to change the inhibit delay to 2seconds in /etc/systemd/logind.conf: InhibitDelayMaxSec=2 Now the misbehaving mission-control inhibitor is inhibiting for only 2 seconds.
(In reply to comment #1) > Why does telepathy do that? If you shutdown without disconnecting the > connection will timeout anyway. This is kind of a pointless thing to do. See https://bugs.freedesktop.org/show_bug.cgi?id=68758
I discovered today that this issue also affects Fedora 20 which ships telepathy-mission-control 5.16. If this issue is not fixed, more and more systems will be affected with newer version of software. And GNOME will get the reputation to take 5 more seconds (during which it does nothing) to shut down than all other desktop environments...
(In reply to comment #6) > (In reply to comment #1) > > Why does telepathy do that? If you shutdown without disconnecting the > > connection will timeout anyway. This is kind of a pointless thing to do. > > See https://bugs.freedesktop.org/show_bug.cgi?id=68758 That's just a workaround / hack for a server issue on the client side. What if your wireless connection just drops? What if the user disables wifi? Unplug a network cable? ...
(In reply to comment #0) > gdm to get the inhibitor unintentionally since gnome-shell depends on > mission-control to function. No it doesn't.
(In reply to comment #9) > (In reply to comment #0) > > gdm to get the inhibitor unintentionally since gnome-shell depends on > > mission-control to function. > > No it doesn't. But gnome-shell does requires telepathy-mission-control in many distributions like Ubuntu (http://packages.ubuntu.com/precise/gnome-shell), Debian (http://packages.debian.org/wheezy/gnome-shell), and Arch Linux (https://www.archlinux.org/packages/extra/x86_64/gnome-shell/). And the problematic telepathy-mission-control 5.16.0 is even recommended officially (See https://mail.gnome.org/archives/distributor-list/2013-October/msg00000.html).
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #0) > > > gdm to get the inhibitor unintentionally since gnome-shell depends on > > > mission-control to function. > > > > No it doesn't. > > But gnome-shell does requires telepathy-mission-control in many distributions That may be the case but the statement "gnome-shell depends on mission-control to function" is still wrong. Anyway I have no idea how to fix this one. Maybe missing-control should only take the inhibitor when the user is actually logged in and not just when the service is running? Or what exactly is the issue here? I can't imaging logout taking that long. Given that I don't use it here and am not really sold on the "must logout on shutdown" thing (can't work in many cases and having a 4 hours server side timeout is just plain BROKEN) and I have no time to debug it right now someone else has to look into it. Guillaume? Any idea why it does not release the inhibitor? Do we have to ask it to logout / disconnect?
First step would be to get logs from mission-control to see why it's taking so long. We can grab them using empathy-debugger, or by starting MC manually with MC_DEBUG=all G_MESSAGES_DEBUG=all.
Created attachment 266632 [details] mission_control_logs Guillaume, I started mission-control-5 as follows: MC_DEBUG=all G_MESSAGES_DEBUG=all /usr/lib/telepathy/mission-control-5 > mission_control_logs Then 5 seconds later, I pressed the laptop power button which is configured to sleep. 5 seconds later the laptop went to sleep, and finally 5 seconds later I woke the computer up and SIGINT mission-control. Please find the mission_control_logs attached.
Seems that mission-control-5 will immediately get the inhibitor -- with or without gnome-shell... I wonder whether it is the fault of mission-control or gnome-shell. Should gnome start mission-control on demand or should mission-control inhibits when there is active connection?
OK, MC has fixed that problem (see https://bugs.freedesktop.org/show_bug.cgi?id=73599) and the patch given patch works on my system. MC will properly release inhibitors on shutdown in future versions.