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 727049 - Logout delay on gnome-shell-3.12.0
Logout delay on gnome-shell-3.12.0
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: general
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
3.12.1
: 727092 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-03-25 21:43 UTC by Armin K.
Modified: 2014-03-26 19:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
main: Unown our DBus name when gnome-session says "Stop" (2.27 KB, patch)
2014-03-26 14:55 UTC, Rui Matos
committed Details | Review
main: Unown our DBus name when gnome-session says "Stop" (2.71 KB, patch)
2014-03-26 19:08 UTC, Rui Matos
committed Details | Review

Description Armin K. 2014-03-25 21:43:14 UTC
When I click on "Log out", I have to wait at least 60 seconds before I actually log out. I can continue using the system just fine after I confirm the logout, but then it will just throw me back to gdm after some time.

I have built latest GNOME components released yesterday and today (Monday and Tuesday), without any patching or such. I'm using systemd stock version 211, also without any patches.
Comment 1 Mantas Mikulėnas (grawity) 2014-03-25 23:30:30 UTC
I noticed that gnome-settings-daemon remains running even after receiving EndSession from gnome-session (it was the only client listed in `gdbus call -e -d org.gnome.SessionManager -o /org/gnome/SessionManager -m org.gnome.SessionManager.GetClients`). Killing it makes the logout instant.
Comment 2 Rui Matos 2014-03-26 14:47:46 UTC
This is a side effect of https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=e73148e492ff8bfa65e2195cb5002442966c58e1. Working on a fix
Comment 3 Rui Matos 2014-03-26 14:55:17 UTC
Created attachment 273001 [details] [review]
main: Unown our DBus name when gnome-session says "Stop"

We don't want to quit yet because if we do, gnome-shell and still
mapped windows lose their theme and icons. But we have to unown our
DBus name otherwise gnome-session will hang waiting for us.
Comment 4 Rui Matos 2014-03-26 14:56:28 UTC
*** Bug 727092 has been marked as a duplicate of this bug. ***
Comment 5 Allison Karlitskaya (desrt) 2014-03-26 16:18:16 UTC
Review of attachment 273001 [details] [review]:

I'm not sure why this works, but it does.
Comment 6 Rui Matos 2014-03-26 17:49:12 UTC
(In reply to comment #5)
> Review of attachment 273001 [details] [review]:
> 
> I'm not sure why this works, but it does.

It works because gnome-session monitors NameOwnerChanged on the bus and if the name going away matches the name of a client that was previously registered, that client is marked as disconnected and thus the EXIT phase won't wait for it.
Comment 7 Ray Strode [halfline] 2014-03-26 17:59:06 UTC
(In reply to comment #5)
> Review of attachment 273001 [details] [review]:
> 
> I'm not sure why this works, but it does.

Looks like it's because of this code:

static void•
bus_name_owner_changed (DBusGProxy  *bus_proxy,•
                        const char  *service_name,•
                        const char  *old_service_name,•
                        const char  *new_service_name,•
                        GsmManager  *manager)•
{•
        if (strlen (new_service_name) == 0•
            && strlen (old_service_name) > 0) {•
                /* service removed */•
                remove_inhibitors_for_connection (manager, old_service_name);•
                remove_clients_for_connection (manager, old_service_name);•
...
}•

so if a service loses a well-known name on the bus (*any* well known name) then it automatically gets unregistered with the session manager (to be clear, old_service_name is a unique bus name, not a well known name, and service_name is a well known name).  That's pretty broken since a service can own multiple names and those names can come and go, but it does mean rtcm's patch is viable.
Comment 8 Ray Strode [halfline] 2014-03-26 17:59:23 UTC
(sorry, midair collision)
Comment 9 Ray Strode [halfline] 2014-03-26 18:04:12 UTC
Review of attachment 273001 [details] [review]:

maybe it would be better to call UnregisterClient instead?

::: gnome-settings-daemon/main.c
@@ +324,3 @@
                    gpointer user_data)
 {
+        if (ignore_name_lost)

i was going to suggest checking if the connection was still open here instead, but that would break --replace i think
Comment 10 Rui Matos 2014-03-26 18:30:38 UTC
(In reply to comment #9)
> Review of attachment 273001 [details] [review]:
> 
> maybe it would be better to call UnregisterClient instead?

Doesn't seem to work. I guess because of this:

gboolean
gsm_manager_unregister_client (GsmManager            *manager,
                               const char            *client_id,
                               DBusGMethodInvocation *context)
{
        GsmClient *client;

        g_return_val_if_fail (GSM_IS_MANAGER (manager), FALSE);

        g_debug ("GsmManager: UnregisterClient %s", client_id);

        client = (GsmClient *)gsm_store_lookup (manager->priv->clients, client_id);
        if (client == NULL) {
...
        }

        /* don't disconnect client here, only change the status.
           Wait until it leaves the bus before disconnecting it */
        gsm_client_set_status (client, GSM_CLIENT_UNREGISTERED);

        dbus_g_method_return (context);

        return TRUE;
}
Comment 11 Ray Strode [halfline] 2014-03-26 18:41:13 UTC
hmm, okay, so what about closing the connection?  The thing i'm worried about is, down the line we'll probably want to fix that bug gnome-session code above, and when we do it would be good if we didn't regress this fix.
Comment 12 Rui Matos 2014-03-26 18:41:53 UTC
(In reply to comment #7)
> so if a service loses a well-known name on the bus (*any* well known name) then
> it automatically gets unregistered with the session manager (to be clear,
> old_service_name is a unique bus name, not a well known name, and service_name
> is a well known name).  That's pretty broken since a service can own multiple
> names and those names can come and go, but it does mean rtcm's patch is viable.

Hmm, are you sure about this? I'm not very familiar with dbus-glib code but it seems to me that the only name that can be matched here is the one that you get by calling dbus_g_method_get_sender() on the RegisterClient call because this is the name that gets stored in the GsmDBusClient instance and it's the one that's used to match in _disconnect_dbus_client().
Comment 13 Rui Matos 2014-03-26 18:43:15 UTC
(In reply to comment #11)
> hmm, okay, so what about closing the connection?  The thing i'm worried about
> is, down the line we'll probably want to fix that bug gnome-session code above,
> and when we do it would be good if we didn't regress this fix.

Disconnecting from the bus means that we won't die when the bus dies isn't it?
Comment 14 Rui Matos 2014-03-26 19:08:20 UTC
Created attachment 273017 [details] [review]
main: Unown our DBus name when gnome-session says "Stop"

We don't want to quit yet because if we do, gnome-shell and still
mapped windows lose their theme and icons. But we have to unown our
DBus name otherwise gnome-session will hang waiting for us.

This only works due to a bug in gnome-session where it handles any
client name being unowned as if the client has disconnected. Will need
to be revisited when that bug is fixed in gnome-session.
--

After talking with Ray on IRC we decided to push this patch for now
with the expanded comment above since this is relying on a
gnome-session bug.
Comment 15 Rui Matos 2014-03-26 19:09:58 UTC
Attachment 273001 [details] pushed as a78caba - main: Unown our DBus name when gnome-session says "Stop"
Attachment 273017 [details] pushed as a78caba - main: Unown our DBus name when gnome-session says "Stop"