After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 359617 - Sometimes bonobo-activation-server does not terminate
Sometimes bonobo-activation-server does not terminate
Status: RESOLVED FIXED
Product: bonobo
Classification: Deprecated
Component: libbonobo
unspecified
Other All
: Normal major
: ---
Assigned To: Michael Meeks
bonobo qa
Depends on:
Blocks:
 
 
Reported: 2006-10-04 14:49 UTC by padraig.obriain
Modified: 2009-03-07 14:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Patch which seems to fix the problem for me. (3.09 KB, patch)
2006-10-05 10:34 UTC, padraig.obriain
needs-work Details | Review
Process list when bonobo-activation-process dies (4.53 KB, text/plain)
2006-10-05 10:52 UTC, padraig.obriain
  Details
Process list when bonobo-activation-server does not die (4.63 KB, text/plain)
2006-10-05 10:53 UTC, padraig.obriain
  Details

Description padraig.obriain 2006-10-04 14:49:32 UTC
Please describe the problem:
When I log out of a GNOME session sometimes bonobo-activation-server does not terminate.

When this happens logging into another GNOME session has some strange effects, e.g. the DBUS_SESSION_BUS_ADDRESS in bonobo-activation-server has the wrong value

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
No.

Other information:
I have atruss file which shows that after active_server_cnx_broken is called for the last time the functiuon prune_dead_servers does not prune OAFIID:Nautilus_Factory
Comment 1 Michael Meeks 2006-10-04 16:18:48 UTC
yes, I can imagine this is horrific :-)
And - indeed, I've seen b-a-s lingering on after people have logged out - however , it -should- die when all it's clients exit.
Question is - why isn't it ? :-) a complete process dump might reveal any lingering clients, then we need to attach to them and work out why they didn't quit.
There's no chance you were debugging one of these processes & it's exited but not really quit properly somehow ?

And - wow, long time no see Padraig :-) hope life is going well for you.
Comment 2 padraig.obriain 2006-10-05 07:56:30 UTC
Life would be almost perfect if I could make this bug go away.

I see no evidence of lingering clients and I am not debugging any processes.

What I am seeing suggests some sort of timing issue.

active_server_cnx_broken is called for the last server connection.
The function as_rescan is called and prune_dead_servers is called. 
ORBit_small_get_connection_status does not return ORBIT_CONNECTION_DISCONNECTED
for the connection for which active_server_cnx_broken was called so we
are left with 1 life server.
Comment 3 Michael Meeks 2006-10-05 09:56:52 UTC
So - the code looks good - if we get another 'broken' callback while re-scanning, we do another re-scan at idle: that seems robust to me over all forms of re-enterancy there.

So - at the end of the day, we call ORBit_small_connection_get_status on that handle - and it doesn't return DISCONNECTED: why is that ?

I'm still suspicious of lingering clients though - can you attach your complete process list ? :-)

One possibility is that you're using IPv4 sockets for something [ although ~everything registered with b-a-s should be UDS based I think ], and that they have far weaker timeout/disconnect semantics - that require data to be written to them in order to detect this case. ie. you perhaps want to ping the client to provoke the disconnect; but - well, it works for me.

Can you find what socket the connection has, the status of that socket, what it's connected to remotely [lsof/fuser helps on Linux] etc. ?
Comment 4 padraig.obriain 2006-10-05 10:34:45 UTC
Created attachment 74043 [details] [review]
Patch which seems to fix the problem for me.

I have not yet had a chance to study your last comment.

The attached patch which fixes the problem for me hopefully gives some indication of what is going wrong.
Comment 5 padraig.obriain 2006-10-05 10:52:36 UTC
Created attachment 74046 [details]
Process list when bonobo-activation-process dies
Comment 6 padraig.obriain 2006-10-05 10:53:38 UTC
Created attachment 74047 [details]
Process list when bonobo-activation-server does not die
Comment 7 padraig.obriain 2006-10-05 10:55:47 UTC
Hopefully, the process list will set your mind at rest about lingering clients.

I have noticed that the problem is more likely to occur if I log out immediately after logging in.

What triggers active_server_cnx_broken to be called?
Comment 8 Kjartan Maraas 2006-10-30 09:34:38 UTC
Michael, does this look ok to commit?
Comment 9 Michael Meeks 2006-10-30 09:55:27 UTC
Padraig - I don't like the idea of giving up and re-scanning after a second really - I'd prefer to get to the bottom of why the lifecycle isn't working correctly.

There is another bug open wrt. lifecycle that is similar - and (I think) entirely Unix Socket based, so perhaps there is a deeper problem here that this just hides: cf. #365206#.

OTOH - if it works around the problem to most people's satisfaction, then perhaps it is ok. FWIW, I don't like the solution to 365206 either. so ...
Comment 10 padraig.obriain 2006-10-31 13:39:11 UTC
I had intended my patch to be a workaround which, hopefully, demonstrated the problems I am seeing and allowing a proper fix to be developed.
Comment 11 Kjartan Maraas 2007-01-10 14:21:35 UTC
Marking the patch as needs-work based on comment #10.
Comment 12 Sergey V. Udaltsov 2007-03-30 07:55:41 UTC
Any progress on this one? I causes the problems for the applets using DBUS (like keyboard indicator).
Comment 13 Gustavo Carneiro 2007-03-31 13:36:25 UTC
I should point out that there is a way for activation clients to force the refresh of certain variables without forcing b-a-s to restart.  See bug 389984.
Comment 14 Pacho Ramos 2008-09-22 12:07:31 UTC
This should be fixed in trunk as no it quits when dbus exits
Comment 15 Kjartan Maraas 2009-03-07 14:51:04 UTC
Closing based on comment #14.