Bug 110564

Summary: bonobo-activation-server behaves badly after subsequent evolution sessions
Product: [Fedora] Fedora Reporter: Paul W. Frields <stickster>
Component: libbonoboAssignee: Jonathan Blandford <jrb>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: ddumas
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-02 22:07:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of GNOME settings daemon errors none

Description Paul W. Frields 2003-11-21 13:09:36 UTC 
Description of problem:

After launching evolution more than once during a GNOME session,
bonobo-activation-server does not quit properly at the end of the
GNOME session.


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

1.0.22-7

How reproducible:

Always.

Steps to Reproduce:
1. Login to GNOME.
2. Start evolution, optionally perform tasks, quit evolution.
3. Start evolution again, optionally perform tasks, quit evolution.
4. Logout of GNOME session.
5. Login to GNOME.
  
Actual results:

GNOME settings daemon errors along with applet loading problems,
apparently caused by bonobo-activation-server not understanding we are
in a new session.

Expected results:

Nominal behavior.

Additional info:

This is probably related to bug #106826, #109449, and possibly others.
Comment 1 Paul W. Frields 2003-11-21 13:10:21 UTC 
Created attachment 96117 [details]
Screenshot of GNOME settings daemon errors
Comment 2 Mark McLoughlin 2004-07-28 12:00:39 UTC 
(Sorry about the inactivity here)

Do you still see this issue in FC2? I've a vague recollection it has
since been fixed.
Comment 3 Paul W. Frields 2004-08-02 22:07:24 UTC 
Problem as stated is solved. I still occasionally see problems on a
box at work that authenticates via SMB (NT domain), but I haven't even
been able to reproduce that reliably. This should be closed.