Bug 138144 - (IT_53031) bonobo-activation-server doesn't exit after session closed if evolution has been run
bonobo-activation-server doesn't exit after session closed if evolution has b...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: evolution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
Depends On:
Blocks: 136201
  Show dependency treegraph
Reported: 2004-11-04 17:59 EST by David Lehman
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-12 11:57:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch that attempts to listen for client disconnections (2.03 KB, patch)
2005-01-04 21:15 EST, Dave Malcolm
no flags Details | Diff
patch for negative server count problem (579 bytes, patch)
2005-02-18 06:00 EST, Mark McLoughlin
no flags Details | Diff

  None (edit)
Description David Lehman 2004-11-04 17:59:40 EST
Description of problem:
If evolution is run during a GNOME session, the bonobo-activation-server and
evolution-wombat processes don't exit when the user logs out of the desktop.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Log into GNOME as a non-root user 
2. Start evolution, then stop it once it's up
3. Log out of the desktop
Actual results:
Both processes remain:
[root@hogwash root]# ps -few | grep bonobo
tester   31084     1  0 16:54 ?        00:00:00
/usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=16
[root@hogwash root]# ps -few | grep evolution
tester   31126     1  0 16:54 ?        00:00:00
--oaf-activate-iid=OAFIID:GNOME_Evolution_Wombat_InterfaceCheck --oaf-ior-fd=24

Expected results:
All processes related to the desktop session terminated when session ended.

Additional info:
Killing the evolution-wombat process manually (SIGTERM) causes the b-a-s process
to exit, but the opposite is not true.
Comment 1 Dave Malcolm 2004-11-17 13:42:16 EST
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...
Comment 2 Dave Malcolm 2004-11-17 18:24:34 EST
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.
Comment 3 David Lehman 2004-11-18 12:31:40 EST
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).
Comment 4 Dave Malcolm 2004-11-18 13:45:22 EST
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.
Comment 5 David Lehman 2004-11-18 13:55:53 EST
Right. No evolution-connector either.

The simplified experiment worked also:

18299 ?        S      0:00 /usr/libexec/bonobo-activation-server --ac-activate
18303 ?        S      0:00 /usr/libexec/evolution/1.4/evolution-alarm-notify

I'm not sure if the evo-alarm-notify process should be running, but it gets
killed if I log out.
Comment 6 David Lehman 2004-11-18 13:57:27 EST
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.
Comment 7 Dave Malcolm 2004-11-18 14:36:16 EST
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.
Comment 8 David Lehman 2004-11-18 14:46:11 EST
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.
Comment 10 Mark McLoughlin 2004-11-22 10:46:02 EST
Dave: definitely looks to be a wombat problem. Here's what I did:

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),

** (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.
Comment 11 Dave Malcolm 2004-12-06 19:07:53 EST
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.
Comment 12 Dave Malcolm 2004-12-14 17:53:43 EST
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
file:///home/test_dhm/evolution/local/Tasks/tasks.ics: 0x9e4e280
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)
Comment 13 Dave Malcolm 2004-12-14 18:00:50 EST
(i.e. that there is/are calendar client connection(s) holding alive
the backends inside the wombat process).
Comment 14 Dave Malcolm 2004-12-14 18:16:37 EST
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.
Comment 16 Mark McLoughlin 2004-12-15 03:29:13 EST
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.
Comment 17 Dave Malcolm 2005-01-04 21:13:22 EST
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?
Comment 18 Dave Malcolm 2005-01-04 21:15:22 EST
Created attachment 109352 [details]
Patch that attempts to listen for client disconnections

Doesn't yet work, as described in comment 17
Comment 19 Havoc Pennington 2005-01-04 22:31:21 EST
Does linc have HUP/ERR (G_IO_HUP/G_IO_ERR or whatever) in the flags
for the IO watch?
Comment 20 Mark McLoughlin 2005-01-05 04:54:35 EST
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.
Comment 21 Dave Malcolm 2005-02-17 17:13:55 EST
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)
Comment 22 Dave Malcolm 2005-02-17 18:35:36 EST
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

markmc: what version number should I give the new bonobo-activation
Comment 23 Mark McLoughlin 2005-02-18 06:00:11 EST
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.
Comment 24 Dave Malcolm 2005-02-28 14:43:10 EST
I tried out the patch in comment #23 and it fixes the remaining problem.

Building fixed bonobo-activation package and evolution packages into
Comment 26 Jay Turner 2005-05-12 11:57:00 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.