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): evolution-1.4.5-1 How reproducible: Always 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 /usr/libexec/evolution/1.4/evolution-wombat --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.
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