Bug 247756 - The gnome panel encountered a problem while loading "OAFIID:GNOME_MiniCommanderApplet"
Summary: The gnome panel encountered a problem while loading "OAFIID:GNOME_MiniCommand...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-applets
Version: 7
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
: 200232 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-11 09:56 UTC by Joachim Backes
Modified: 2008-06-17 05:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-17 01:51:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Joachim Backes 2007-07-11 09:56:36 UTC
Description of problem:
After having updated from FC6 to F7, I'm still using the GNOME desktop.
Sometimes having problems to add an applet to the gnome-panel: If selecting the
applet from the applet selection box and clicking on "Add", after some seconds
getting an error prompt containing:

The panel encountered a problem while loading
"OAFIID:GNOME_MiniCommanderApplet".Do you want to delete the applet from your
configuration?

The same happens sometimes directly when logging in via gdm (it seems  the
gnome-panel containing applets cannot be rebuilt).

Version-Release number of selected component (if applicable):
gnome-panel-2.18.3-1.fc7

How reproducible:
Very often, not always.

Steps to Reproduce:
1. Login into the gnome desktop
2.Tray to add some applet to the panel
3.
  
Actual results:

Rejected with the message:
The panel encountered a problem while loading
"OAFIID:GNOME_MiniCommanderApplet".Do you want to delete the applet from your
configuration?
Expected results:
Applet is added

Additional info:
1. Never had such problems in FC6
2. Most times, the problem occurs when logging in via NX/2x client

Comment 1 Joachim Backes 2007-07-11 09:58:55 UTC
The behaviour does not depend from the applet. It likewise appears for example
with the clock applet.

Comment 2 Joachim Backes 2007-07-11 12:22:32 UTC
I found out that

rm -rf /tmp/orbit-<user>

helps (until the next time the problem occurs).

Comment 3 Robin Laing 2007-07-30 02:26:19 UTC
I had the same issue and removing /tmp/orbit-<user> fixed one problem but
created another.  I had to remove anything related to the <user> in the /tmp
directory.

I needed to

rm -rf orbit-<user>
rm -rf virtual-<user>*
rm -rf ksocket-<user>
rm -f mapping-<user>
rm -rf gconfd-<user>

All the problems occurred after using switching user.

I am not sure which one was the final fixer but I deleted all files in the /tmp
related to the user.




Comment 4 David Hislop 2007-09-17 07:20:29 UTC
Similar issue, applied fix above in Comment #3, and it worked.

Difference was in my case it was
1. ALL applets threw up the error.
2. It only happened on an XWindows connection; the console did not have the problem.

If anyone wants the contents of the /tmp files for debugging, I've saved them.

Comment 5 Gabriel M. Elder 2007-09-26 14:04:25 UTC
bug # 200232 may be related (should be marked duplicate of this?)

Comment 6 Matthias Clasen 2007-09-26 15:53:04 UTC
*** Bug 200232 has been marked as a duplicate of this bug. ***

Comment 7 Paul Coccoli 2008-03-05 14:47:28 UTC
This happens periodically on all of my F7 boxes.  I think it results from
bonobo-activation-server not exiting on session logout.  Killing that process
fixes it, but I haven't yet found the proper place to call a script and kill it.

This problem happens on my wife's account often, and it drives her nuts because
the error dialog is almost meaningless, even to me.

Comment 8 Gabriel M. Elder 2008-03-05 15:50:42 UTC
After monkeying with this a while back, I was able to make a few observations
regarding this bug, which others might find helpful:

0) This bug can consistently be reproduced by deleting the
/tmp/orbit-$USER/bonobo-activation-server-ior state file, logging in as that
$USER on any virtual terminal / X display number, logging out, then logging in
as that same $USER on SOME OTHER virtual terminal / X display number.  This
state file seems to contain a "stale" ORB reference when sessions occur on
differing virtual terminals.

1) Once this state file is deleted and subsequently recreated the next time the
user logs in, they will not get these error messages again, so long as they
continue to use the same virtual terminal for their gnome sessions each time
they log in.

2) The OAFIID error messages only occur each time a user logs into their gnome
desktop via an X display/virtual terminal other than the first one they logged
into in which the bonobo-activation-server state file was initially created. For
instance, if Jane logs into gnome on the first/default X session on display :0
(located at ctrl+alt+f7) for the first time, logs out, then later starts a new
login session and logs into her gnome desktop on display :1 (located at
ctrl+alt+f9 on my box) because Joe is already logged in on display :0, she will
get the error messages for each gnome panel applet that is trying to load. The
applets cannot load because the bonobo-activation-server-ior state file is
telling them that they need to work with an ORB process associated with an X
session using the virtual terminal / display number specified by the state file
at the time of its creation, i.e. at the first log in where the
bonobo-activation-server-ior did not already exist. More simply stated, in this
example the ORB state file (or the bonobo-activation-server process itself?) is
still referencing display :0, while the user is on display :1, hence the applets
spit out the error messages.

3) Therefore, if you delete /tmp/orbit-$USER/bonobo-activation-server-ior each
time after logging out, the $USER in question will not get these error messages
the next time they log into their desktop, regardless of what virtual terminal
they log in to.

Any workarounds should be derived from these facts, until such time as this bug
is Fixed.

Personally, I have since installed fedora 8 (backup, wipe partition, then fresh
install), where multiple user desktops and login sessions seem to be handled
much more smoothly (including audio - Yay, ConsoleKit!), and this bug does not
seem to be present.

Comment 9 Bug Zapper 2008-05-14 13:30:41 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bug Zapper 2008-06-17 01:51:17 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 11 Joachim Backes 2008-06-17 05:17:35 UTC
CAnnot be reproduced in F9!


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