we are seeing same issue on mandriva cooker

This bug is rather severe as it breaks things after relogin. Now in LTSP environments relogins is what you got 1000 times a day. So you end up with tons of orphaned processes and the desktop not working for the users.

In the light of this, please increase the importance of this bug and get a fix out there soon as it renders gnome 2.18 unusable for LTSP environments.

setting severity: major.

Isn't this closely related to this:

http://bugzilla.gnome.org/show_bug.cgi?id=152907

Created attachment 90890 [details]
ps axu | grep USERNAME

esd stays active too
Anyway, I hope esd will be discarded in favor of pulseaudio soon!

Here is a list of all processes which stay active after logout on my Ubuntu Feisty installation:

elias     5751  0.0  0.2  39700  3264 ?        Ssl  19:53   0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=16
elias     6051  0.0  0.6  68160  9892 ?        Sl   19:54   0:00 /usr/lib/evolution/evolution-data-server-1.10 --oaf-activate-iid=OAFIID:GNOME_Evolution_Data
Server_BookFactory:1.2 --oaf-ior-fd=43
elias     7084  0.0  0.0   1712   468 ?        Ss   20:17   0:00 /bin/sh -c /usr/bin/esd -terminate -nobeeps -as 1 -spawnfd 29
elias     7085  0.0  0.0   3316  1512 ?        S    20:17   0:00 /usr/bin/esd -terminate -nobeeps -as 1 -spawnfd 29
elias     7093  0.0  0.1   4776  2220 ?        S    20:17   0:00 /usr/lib/libgconf2-4/gconfd-2 14

Most processes started by the gnome-session-manager get closed however. Therefore, I would not think this is related to the bug mentioned above. But what do I know.

Please have a look at these two bug reports for additional information:
https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/90258
https://bugs.launchpad.net/ubuntu/+source/libbonobo/+bug/90923

The problem is, that somehow the addressbooks are kept open. It seems like the finalize-function does not unref/close/free (?) the referenced books properly.

The following is called in e_cal_backend_contacts_finalize:

g_hash_table_destroy (priv->addressbooks);
g_hash_table_destroy (priv->tracked_contacts);
g_hash_table_destroy (priv->zones);

I'm not an experienced programmer, and not familiar with e-d-s and glib stuff, but I've compared the finalize-functions of different evolution-backends. evolution-jescs (calendar/cal-backend-wcap.c) e.g. uses such GHashTables, too, but there the finalize_handler for a GHashTable looks like this:

in cal_backend_wcap_finalize you'll find:

if (priv->objects) {
 g_hash_table_foreach (priv->objects, (GHFunc) destroy_object_hash, NULL);
 g_hash_table_destroy (priv->objects);
 priv->objects = NULL;
}

where destroy_object_hash-function looks like this:

static void
destroy_object_hash (gpointer key, gpointer value, gpointer user_data)
{
	g_free (key);
	g_object_unref (G_OBJECT (value));
}

I may be wrong, but is it possible that a simple "g_hash_table_destroy" is not enough to close all addressbooks?

Hmpf, sorry for the above nonsense - the mentioned part of evolution-jescs is using g_hash_table_new () instead of g_has_table_new_full () (like e-cal-backend-contacts.c does) for creation of the given GHashTables. 

But this leads me to the assumption, that one of the callback-functions - either "book_record_free ()" or "contact_record_free ()" - is not cleaning up the whole show. Either one of the given callback-function is missing something, or the finalize-function has to be extended, so that the address-books are closed down with the rest of e-d-s, too. Any hints, what exactly this may be?

Created attachment 91997 [details] [review]
Patch for e-d-s-1.10.2 termination failure

Free subcomponents of static timezone struct

I've had this problem on Fedora 7 with e-d-s-1.10.2, but didn't have it on Fedora Core 6 with e-d-s-1.8.3, so I compared the two, and noticed in calender/backends/contacts that there was a single fix to e-cal-backend-contacts.c that looked like it was trying not to free a static structure.  I think the problem with the fix is that the static structure has dynamically allocated components that thus weren't getting freed, and those seem for me to have been the cause of the failure to terminated.  I adjust the fix to free the components but not the static struct itself (there was already a mechanism in place for that).

Sorry for the typos...

I meant to mention that I don't consider my patch a complete fix - it's just a workaround I think others having the problem might try.  I wouldn't be surprised if this comes up again somewhere else involving bonobo-activation-server.

The utc timezone is not freed since its a static struct defined
as below,
static icaltimezone utc_timezone = { 0, 0, 0, 0, 0, 0, 0, 0, 0 };

And the get_utc_timezone returns the address of that structure 
return &utc_timezone;

If you pass 0 to icaltimezone_free, it would try to free the internal elements in icaltimezone structure and reintialize the values. But since all the internal elements are just 0 in this case, it doesnt make much sense to call it for utc timezone.

I've been struggling with vnc, ltsp and b-a-s on RedHat's Fedora. Could these bugs be related? A number of gnome panel apps crash in follow-on sessions.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=245525">RH bug 245525</a>

I've done some research on this bug :

e-d-s not exiting is caused by contacts (ie birthday) backend of calendar component.

When contacts backend is disabled, e-d-s is exiting correctly.

You get the broken behaviour with either alarm-notify, gnome-panel clock applet (after opening it one time) or dates (easier to reproduce with date).

the call to e_book_new (sources, NULL) in e-cal-backend-contacts.c (even, for test purpose, followed by a g_object_unref (book) and return NULL in book_record_new is causing the component leakage.

It seems the leak is in addressbook component.

(In reply to comment #15)
> I've done some research on this bug :
> 
> e-d-s not exiting is caused by contacts (ie birthday) backend of calendar
> component.
> 
> When contacts backend is disabled, e-d-s is exiting correctly.
> 
> You get the broken behaviour with either alarm-notify, gnome-panel clock applet
> (after opening it one time) or dates (easier to reproduce with date).
> 
> the call to e_book_new (sources, NULL) in e-cal-backend-contacts.c (even, for
> test purpose, followed by a g_object_unref (book) and return NULL in
> book_record_new is causing the component leakage.
> 
> It seems the leak is in addressbook component.
> 

Read my comment (#11).  I already found a leak in e-cal-backend-contacts, and submitted a patch for it.

But I think the problem is bigger than just this leak.

Try the patch; see it it helps; go from there...

John, your patch fixes a memory leak, not a reference leak. And this bug is caused by a reference leak and won't be fixed by plugging memory leaks (unless they are coupled with ref leak :)

Created attachment 96682 [details] [review]
proposed eds patch (ref/unref only)

for evolution-data-server;

Here's a patch for ref/unref part of this bug *only*. I tested it with evolution-alarm-notify and when applied then eds closes a bit after alarm-notify is closed.

Created attachment 96692 [details] [review]
proposed eds patch (ref/unref only) ][

for evolution-data-server;

My first patch worked only when there was at least one contact with birthday or anniversary. This one seems like working even without any contact with birthday or anniversary.

(In reply to comment #17)
> John, your patch fixes a memory leak, not a reference leak. And this bug is
> caused by a reference leak and won't be fixed by plugging memory leaks (unless
> they are coupled with ref leak :)
> 

I didn't expect it would fix the problem entirely - I said as much; and I didn't
classify the leak(s) it fixes.  But it did help in my case.  For a while I wasn't
having the problem at all, though it's back now (on Fedora 7).

I'm not an Evolution developer; I'm a Fedora user.

I don't even like Evolution, but this stuff is so wired into GNOME that I can't
easily get rid of it (I've tried).

Milan, I'll try your patch... 8^)

E-D-S after applying commited patch seems to exit gracefully, tested with evo 2.12 and eds 1.12.

I can confirm Milan latest patch fixes the issues when no contact has birthday / anniversary set or if one has (sorry Milan for false tests this morning, it seems my test system was a little too much instable).

Would it be possible to get a review of Milan patch ? This bug is quite visible on a lot of distributions and it would be great to have it fixed for e-d-s 1.12.1

I meant to reply that it seems to be working for me also, Milan & Frederic, but I haven't agressively tested it (nor am I really equipped to do so), and I only have it applied to 1.10.3.1, which is Fedora 7's currently released version.  I'm not involved with the maintenance of this package on Fedora or elsewhere.

I would mention, though, since I saw this early, that a quick login/logout doesn't tickle the bug; for me, it takes about a minute after login for e-d-s to start.

Thanks for your good efforts, Milan (and you too, Frederic). 8^)

book->priv->corba_book has to be initialized to CORBA_OBJECT_NIL and not NULL.
I can see that it works fine for me also. I think we can push this to head and stable then. 

Committed to trunk. Committed revision 8110.
Committed to stable. Committed revision 8111.

Fixed my fault. I kept this opened because of the first patch from comment #10, which is marked as 'Reviewed' right now, even I think it doesn't make sense to clear that data, so it should be 'rejected' instead, but I'm not sure about it.

Tihs bug is still occurring for me on e-d-s 1.12.1. This bug has been occurring for me since gnome 2.16 when I filled in the contacts, appointments. For a while I've been moving the libecalbackendcontacts.so to roots home so I have a backup of the current version. 

Is it possible that you've there some kind of mess with those backuped files? May be better, same as Frederic explained above, can you provide some additional information how to reproduce it? I can imagine that evolution crashed and then the eds will not be closed properly, because crashed evolution kept reference to it. Also, when you run evolution --force-shutdown then the bonobo server will still run, because killed eds/evo will not unref what has referenced. I'm just guessing...

It's happening again for me now; there's a stale bonobo-activation-server hanging
around after logout, but no e-d-s.

ok, if bonobo stayed opened, then use bug 303083, instead of this, please.

(I'm sorry for spam, I forget to keep this opened because of patch from 2007-07-19.)

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

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

Do you still have this problem? can we close the bug?

Now, I can reproduce this bug at ubuntu 8.10 and solaris 11.
After I log out and log in many times, there will be several evolution-data-server processes.
Now I log on as user liushuai, and I can see the process here:

liushuai@golf:~$ ps -ef | grep evolution-data-server
liushuai  3290     1  0 11:09 ?        00:00:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=30
test100   5111     1  0 15:28 ?        00:00:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=23
liushuai  6725     1  0 15:35 ?        00:00:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=27
liushuai  6900  6762  0 16:04 pts/0    00:00:00 grep evolution-data-server

By the way, I use evolution and evolution-data-server 2.23.91.

I still suffer this with 2.26 under Gentoo

The problem seems to be related with evolution-alarm-notify being still alive when I logout from my gnome-session:
1. Run evolution
2. Close it
3.  $ ps axu | grep evo
pacho     8378  0.0  0.9 334404 20516 ?        Sl   10:20   0:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=23
pacho     8410  0.0  1.0 342908 22588 ?        Sl   10:20   0:00 /usr/libexec/evolution/2.26/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.26 --oaf-ior-fd=25
pacho     8900  0.0  0.0   9976   848 pts/0    R+   10:22   0:00 grep --colour=auto evo

4. Now, logout

---> evolution-alarm-notify is killed but evolution-data-server keeps running forever

Now, try the following:
1. Run evolution
2. Close it
3. kill evolution-alarm-notify
4. If you wait a bit, e-d-s exits itself, if you don't wait and logout directly, it's also properly killed

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

Pacho Ramos, killing evolution-alarm-notify does not help, esp. if you click on the clock applet. It triggers evolution-data-server to be launched to mark events from the evolution calendar.

The e.d.s remains active even after the user logs out.

To reproduce:

1. log in
2. click on the calendar applet
3. logout
4. check processes, there should be an e.d.s still running

Performing the above steps afain makes another e.d.s to be running and so on.

I too have this issue, and have had it for a long time.

If I disable all the the alarm/notify functions that I can find.  Still upon exit, I get these processes...  Here in this snippit, I've got myself, and one user who has actually logged out of their session all together....

This makes a MESS for NFS mounts!

 $ ps -ef | grep evolu
imoss     2016     1  0 16:10 ?        00:00:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=28
imoss     2038     1  0 16:10 ?        00:00:00 /usr/libexec/evolution/2.26/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.26 --oaf-ior-fd=29
imoss     2925  2914  0 16:46 pts/1    00:00:00 grep --colour=auto evolu
bdm       8416     1  0 06:55 ?        00:00:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=26
bdm       9371     1  0 07:57 ?        00:00:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=20


Is there any progress on this issue at all?

Yes, it's already fixed in 2.29 by dropping Bonobo.  Closing as fixed.