After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 690713 - Keyboard shortcut for suspend/hibernate doesn't emit org.freedesktop.UPower.Sleeping() [regression]
Keyboard shortcut for suspend/hibernate doesn't emit org.freedesktop.UPower.S...
Status: RESOLVED NOTGNOME
Product: gnome-settings-daemon
Classification: Core
Component: power
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Richard Hughes
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2012-12-25 17:17 UTC by Kamil Páral
Modified: 2013-02-02 02:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kamil Páral 2012-12-25 17:17:02 UTC
My Jabber client Gajim watches for org.freedesktop.UPower.Sleeping() dbus signal to disconnect from the network. If I suspend the computer using user menu -> (alt) Suspend to RAM, the signal is correctly received and I'm disconnected before suspending. But if I hit the keyboard shortcut (available on my notebook keyboard), the signal is not emitted, the Jabber client does not disconnect, and I'm left hanging seemingly online, but in fact offline, for dozens of minutes. All incoming messages in that time period are lost.

There are definitely other use cases, not just the Jabber client.

I believe the problem is that the menu item uses UPower to trigger computer suspend, but the keyboard shortcut uses pm-utils.

We need to emit the signal in both cases, using system menu or keyboard shortcut.

This is a regression from GNOME 3.4 (Fedora 17), both approaches emit UPower dbus signal there.

gnome-settings-daemon-3.6.3-2.fc18.x86_64
Comment 1 Matthias Clasen 2012-12-28 15:50:07 UTC
The upower signal can't be reliable because the kernel does not offer a suitable api to implement such a signal.
Comment 2 Kamil Páral 2013-01-02 10:44:47 UTC
Sorry, I don't understand. GNOME can send the signal when suspending using the system menu, but can't send the signal when using the keyboard shortcut? That doesn't seem right, it used to work in previous GNOME versions.
Comment 3 Matthias Clasen 2013-01-02 12:42:24 UTC
whether the signal gets emitted or not depends on which mechanism is used to trigger suspend
Comment 4 Kamil Páral 2013-01-02 12:49:21 UTC
Can we wire both mechanisms to the same code path? I.e. the keyboard shortcut would execute exactly the same code as the menu item does.

Why it worked in GNOME 3.4 and now it doesn't in GNOME 3.6? It's not an erratic behavior, it used to work reliably and now it doesn't work at all.
Comment 5 Matthias Clasen 2013-01-02 14:49:04 UTC
it used to work 'reliably' only because everything used to talk to upower.
now, some code paths are going directly to logind.
Comment 6 Bastien Nocera 2013-01-02 15:22:27 UTC
See: https://bugs.freedesktop.org/show_bug.cgi?id=58950
Also note that it only affects the Fedora version of gnome-settings-daemon, as the upstream version (in GNOME 3.6) still uses upower for this.