GNOME Bugzilla – Bug 646117
e-calendar-factory does not exit
Last modified: 2013-09-14 16:54:04 UTC
After logging out using the GNOME dialog (System → Log out) `e-calendar-factory` is still running. $ ps aux | grep -i evol joe 3736 1.1 6.7 306388 266356 ? Sl 6:21 4:25 /usr/lib/evolution/e-calendar-factory joe 30368 0.0 0.0 3320 816 pts/1 S+ 23:19 0:00 grep -i evol I am using Evolution 2.32.2-2 from Debian Sid/unstable. Bonobo is not in Evolution dependency list, so I am wondering if bug #420167 is related to this. PS: I hope I selected the correct component.
I tried reproducing this in a simulated login session: eval `dbus-launch | tee dbus` cat dbus (to find out the dbus-daemon process ID) e-calendar-factory Then I sent a TERM signal to the dbus-daemon as would happen when logging out, and the e-calendar-factory process terminated as expected with the following message: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. I don't know what would be keeping it alive.
I tried reproducing this on an actual GNOME 3.0 environment. Set up a number of calendars, interacted with them, verified e-calendar-factory was running. Then logged out of the session and checked if e-calendar-factory was still running. It was not. Whatever caused the process to stay alive seems to have been fixed, so closing this bug as obsolete. Feel free to reopen if you can reproduce the issue with version 3.0 or later.
This very much is still reproducible, on my system, on davidz's system. Just come by my cube and I show you... Just a wild guess, it might have something to do with this code in libecal/e-cal.c: ‣‧‧‧‧‧‧‧cal_factory_proxy = e_gdbus_cal_factory_proxy_new_for_bus_sync ( ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧G_BUS_TYPE_SESSION, ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧G_DBUS_PROXY_FLAGS_NONE, ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧CALENDAR_DBUS_SERVICE_NAME, ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧"/org/gnome/evolution/dataserver/CalendarFactory", ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧NULL, ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧error); ‣‧‧‧‧‧‧‧if (!cal_factory_proxy) { ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧UNLOCK_FACTORY (); ‣‧‧‧‧‧‧‧‣‧‧‧‧‧‧‧return FALSE; ‣‧‧‧‧‧‧‧} ‣‧‧‧‧‧‧‧connection = g_dbus_proxy_get_connection (G_DBUS_PROXY (cal_factory_proxy)); ‣‧‧‧‧‧‧‧g_dbus_connection_set_exit_on_close (connection, FALSE); Where you create a proxy using the shared session bus connection, then get that connection, and set exit-on-close to FALSE.
Your little testcase probably didn't exhibit the problem because you didn't actually execute the e_cal_activate() function.
That's probably true. My mental model of how the connection stuff works is apparently wrong. I thought we were setting up separate private connections for individual calendars but we're apparently sharing a single connection to talk to multiple bus objects. In that case the exit_on_close() call definitely needs to go.
Unfortunately, in my testing, that was not enough to make it exist with the session.
Not sure how you went about testing, but the gnome-shell calendar may still have been running with the exit_on_close() call.
The gnome-shell calendar does not leak out of the session, so I doubt that it is reponsible here.
It turns out the "Birthdays & Anniversaries" calendar backend is actually talking to e-addressbook-factory as a client, and -both- ECal and EBook suppress "exit on close" for GDBusConnections. So the fact that the calendar server is acting as a client to the address book server is what was keeping the calendar server alive past session termination. Was finally able to reproduce this in a stable environment and verify the fix, so I believe the g_dbus_connection_exit_on_close() calls were the sole culprit after all. Whatever bug(s) that call was supposed to be fixing, we'll figure out a different way. Fixed in master and gnome-3-0 branches: http://git.gnome.org/browse/evolution-data-server/commit/?id=ca553fcb264a09b75b406d2eaed1942dc0af6f50 http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-0&id=6760f863ac6d569d170b7486677ce0e46878b114
*** Bug 645614 has been marked as a duplicate of this bug. ***
*** Bug 645074 has been marked as a duplicate of this bug. ***