GNOME Bugzilla – Bug 625514
[gdbus] Client doesn't recognize server close/crash
Last modified: 2013-09-14 16:53:59 UTC
(To not forget) After rewrite to GDBus from dbus-glib the client structure (EBook/ECal) doesn't recognise server close/crash, the previous version was able to notice that, and take some steps on it. The "closed" GDBusConnection signal seems to be for something else. Also consider calling > g_dbus_connection_set_exit_on_close (connection, FALSE); on each GDBusConnection.
Created attachment 166788 [details] [review] eds patch for evolution-data-server; This makes it notify about server vanishing, but the application crashes in GDBus code, filled as bug #625584, thus waiting on it before committing.
Created attachment 166794 [details] [review] eds patch for evolution-data-server; same as the previous one, just updated for glib 2.25.12.
Created commit 1f06f66 in eds master (2.31.91+)
(In reply to comment #0) > (To not forget) After rewrite to GDBus from dbus-glib the client structure > (EBook/ECal) doesn't recognise server close/crash, the previous version was > able to notice that, and take some steps on it. The "closed" GDBusConnection > signal seems to be for something else. It is unclear to me what "server close/crash" means here. Anyway, as documented, the ::closed signal is emitted the other peer goes away: http://library.gnome.org/devel/gio/unstable/GDBusConnection.html#GDBusConnection-closed If your GDBusConnection is for a message bus connection, the other peer is the message bus daemon. Which means that ::closed is emitted when the login session ends. If the other peer is the end of a private connection, ::closed is emitted when that end dies. > Also consider calling > > g_dbus_connection_set_exit_on_close (connection, FALSE); > on each GDBusConnection. If you are only using message bus connections in your application, you normally _never_ want to do that. If you are using private connections, you never need to do that as it is already set to FALSE on construction. Morale: normally you never ever need to call g_dbus_connection_set_exit_on_close()
From talking further with David on IRC about why e-calendar-factory is surviving the desktop session, I think what we want to do is listen for a SIGTERM, which gets raised in response to the message bus closing, and terminate the main loop regardless of how many client connections are still open. It looks like we're already doing that for SIGQUIT, so maybe this is just a simple signal name mismatch.
I think I'm barking up the wrong tree with the SIGTERM theory. Further comments to bug #646117.