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.

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.

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. ?

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.

Created attachment 74046 [details]
Process list when bonobo-activation-process dies

Created attachment 74047 [details]
Process list when bonobo-activation-server does not die

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?

Michael, does this look ok to commit?

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 ...

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.

Marking the patch as needs-work based on comment #10.

Any progress on this one? I causes the problems for the applets using DBUS (like keyboard indicator).

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.

This should be fixed in trunk as no it quits when dbus exits

Closing based on comment #14.