Looks very similar to bug #134851 (and the related bug #134840),
although I suspect the precise cause is different.  (evolution-wombat
became evolution-data-server in the migration from Evolution 1.4 to
2.0).  I'm investigating...

Current status: I've had intermittent success reproducing this bug on
a test machine, and I've been trying to track down the problem (my
guess is a reference-counting leak at this stage).

Is evolution-exchange installed on the machine where this bug is being
experienced? (it is on my test machine)  I don't yet know if that's a
factor in this.

Note that the evolution-wombat process is designed to persist for 5
seconds after evolution exits, so if you're trying to reproduce this
bug by running evolution, exiting it, and typing "ps x" repeatedly,
expect to see "evolution-wombat" in the output for the first 5
seconds.  It's then _meant_ to go away.

No evolution-exchange on my test box.

I reproduced by logging into desktop, starting evo, exiting evo,
logging out of desktop, then running ps -fe via an existing ssh
session. I've verified it lasts quite a bit longer than five seconds
(I am about to kill one that's over 4 minutes old).

In comment #2, instead of "evolution-exchange" I should have said
"evolution-connector".  Sorry about that.  Please can you clarify
comment #3 in that light - thanks.

Possibly simplifying your recipe in comment #3, can you reproduce by
logging in, starting evo, exiting evo, waiting more than 5 seconds and
then running "ps x" (i.e. without even bothering to logout).  The
evolution-wombat process should have shut down at that point, and it's
a bug if it hasn't.

Right. No evolution-connector either.

The simplified experiment worked also:

18299 ?        S      0:00 /usr/libexec/bonobo-activation-server --ac-activate
--ior-output-fd=16
18303 ?        S      0:00 /usr/libexec/evolution/1.4/evolution-alarm-notify
--oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_Alar

I'm not sure if the evo-alarm-notify process should be running, but it gets
killed if I log out.

Hmm, so I wasn't fully paying attention. I guess the evolution-wombat behavior
is okay. bonobo-activation-server seems to be acting up, though.

The process evolution-alarm-notify is responsible for popping up alarm
dialogs to warn you of appointments; it's meant to outlive evolution
and the wombat (since IIRC it stores a copy of the information it
needs internally).  Am I right in thinking that it successfully goes
away on session end?

Re: comment #5 and comment #6...  now I'm confused.  So am I right in
thinking that my simplified recipe in comment #4 doesn't reproduce the
bug.  Does your recipe in comment #3 reliably reproduce the bug? 
What's the actual bug here?  Thanks.

Sorry for the confusion...

Yes, evolution-alarm-notify goes away at session end.
Yes, evolution-wombat goes away as it should.

It turns out the problem is bonobo-activation-server not going away. I will
reassign this to bonobo-activation.

Dave: definitely looks to be a wombat problem. Here's what I did:

1) Added "export BONOBO_ACTIVATION_DEBUG_OUTPUT=1' to 
   /etc/X11/gdm/Sessions/Default
2) logged in, ran evolution, closed evolution, logged out
3) Looked in ~/.xsesssion-errors

What you see in the end is that evolution-wombat stays running
indefinitely and bonobo-activation-server reports that this is the
reason it is still running:

IID 'OAFIID:Bonobo_CosNaming_NamingContext' (0x80aae78), alive
IID 'OAFIID:GNOME_Evolution_Wombat_InterfaceCheck' (0x80a9680), alive
IID 'OAFIID:GNOME_Evolution_Wombat_ServerFactory' (0x80a98f0), alive
IID 'OAFIID:GNOME_Evolution_Wombat_CalendarFactory' (0x80a9348), alive
IID 'OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory' (0x80a6bf8),
dead

** (process:3916): WARNING **: After prune: 2 live servers

i.e. evolution-alarm-notify has just died and bonobo-activation-server
sees that, but it still sees the wombat objects as being alive.

OK - I can successfully reproduce buggy behaviour as described in
comment #8

Scenario 1: login, logout
Result:  Works OK: bonobo-activation-server goes away

Scenario 2: login, start evolution, quit evolution, logout
Result: Bug.  bonobo-activation-server is still running
(evolution-wombat succesfully goes away shortly after evolution is quit)

Scenario 3: login, start evolution, logout
Result: Bug.  Both bonobo-activation-server and evolution-wombat are
still running

I'm investigating further.

Attaching gdb to the wombat process and running 
(gdb) print pas_book_factory_dump_active_backends (pas_book_factory)
$7 = void
(gdb) print cal_factory_dump_active_backends (cal_factory)
$8 = void

...yields this output to .xsession-errors:
wombat-pas-Message: Active PAS backends
wombat-pcs-Message: Active PCS backends
wombat-pcs-Message:  
file:///home/test_dhm/evolution/local/Tasks/tasks.ics: 0x9e4e280
wombat-pcs-Message:  
file:///home/test_dhm/evolution/local/Calendar/calendar.ics: 0x9e1e1b0

So the problem does appear to be that the _calendar_ code is not being
properly shut down (possibly related to evolution-alarm-notify)

(i.e. that there is/are calendar client connection(s) holding alive
the backends inside the wombat process).

evolution-alarm-notify is missing a bonobo_object_unref on its
singleton alarm_notify object.  This local BonoboObject owns
references to CalClient objects, so failing to properly unref it would
keep these references live within the wombat, and may well be the
cause of this bug (unless there are other CalClient leaks elsewhere in
the code).

I'm going to try patching evolution accordingly, and see what effect
this has on the bug.

You might want to check what happens if evolution-alarm-notify crashes
or is killed because its X connection dies.

You might want to use ORBit_small_listen_for_broken() in
calendar/pcs/cal.c:cal_construct() to detect when the listener
connection dies ... but its probably only worth doing if you can still
see wombat running after normal logout.

Attached is a patch that attempts to use ORBit_small_listen_for_broken
(via e_component_listener) to listen for the listener connection dying
and clean up accordingly.  

Unfortunately, it doesn't work; the disconnection code appears not to
get called when the client dies.  

Looking at ORBit2, it looks like the callback is invoked when a state
transition to LINC_DISCONNECTED occurs on a GIOPConnection.  Looking
at the linc code, it appears that this can only happen when a buffer
becomes overfull, or when a fatal error occurs on a write; it looks
like the other end of the connection dying doesn't trigger it (you
have to send something to it).  Perhaps I should be pinging the
CalListener as well?

Created attachment 109352 [details]
Patch that attempts to listen for client disconnections

Doesn't yet work, as described in comment 17

Does linc have HUP/ERR (G_IO_HUP/G_IO_ERR or whatever) in the flags
for the IO watch?

Yep, it has G_IO_ERR|G_IO_HUP|G_IO_NVAL and transitions to
LINC_DISCONNECTED when any of those conditions occur.

Everything (in evo, the patch and ORBit2) looks right to me - not
obvious why its not working for you.

With the patches I'm often getting negative values reported in
.xsesson-errors by active_server_cnx_broken, eg:
** (process:14344): WARNING **: After prune: -3 live servers
(implying -2 active servers, since RESIDAL_SERVERS is 1)

However, in object-directory-corba.c, the struct typedefed to
impl_POA_Bonobo_ObjectDirectory has the field : guint n_active_servers;
i.e. unsigned.  So the test in check_quit compares the value (2^32)-2
(or thereabouts, my two's complement maths is rusty), rather than -2
against RESIDUAL_SERVERS and always fails to bail out.

Am in process of experimenting with changing to a signed type...
(it gets decremented by remove_active_server and prune_dead_servers)

OK, with a simple signedness fix inside bonobo-activation,
bonobo-activation-server now goes away on logout, both with and
without shutting down evolution manually first. (this is on top of my
fixes to evolution to make the calendars inside the wombat listen for
broken client connections, and to ensure evolution-alarm-notify cleans
itself up).

So the fix involves patching both evolution and bonobo-activation;
however AFAIK if a customer only updates one package without the other
it won't cause additional problems.

I'm a little disturbed about the negative values when pruning dead
servers.

markmc: what version number should I give the new bonobo-activation
package?

Created attachment 111194 [details]
patch for negative server count problem

Try this patch to see if it helps with the negative server count stuff.

Should be fine to have the fix across two packages if you put both packages in
the same errata. bonob-activation packages version would be 2.2.2-1.2E.

I tried out the patch in comment #23 and it fixes the remaining problem.

Building fixed bonobo-activation package and evolution packages into
dist-3.0E-U5-HEAD...

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-428.html