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.

This is a side effect of https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=e73148e492ff8bfa65e2195cb5002442966c58e1. Working on a fix

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.

*** Bug 727092 has been marked as a duplicate of this bug. ***

Review of attachment 273001 [details] [review]:

I'm not sure why this works, but it does.

(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.

(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.

(sorry, midair collision)

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

(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;
}

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.

(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().

(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?

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.

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"