Bug 245525 - Panel applets fail to load on LTSP terminal
Summary: Panel applets fail to load on LTSP terminal
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-panel
Version: 8
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
: 243670 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-25 02:41 UTC by Frank Cox
Modified: 2009-01-09 09:23 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2009-01-09 07:09:05 UTC

Attachments (Terms of Use)
.xsession-errors on panel applet load failure (4.82 KB, text/plain)
2007-08-08 18:26 UTC, Frank Cox
no flags Details

Description Frank Cox 2007-06-25 02:41:55 UTC
Description of problem:
I have a Neoware Capio 616 terminal that I use with ltsp 4.2.
When I first log in at my terminal, none of my panel applets start.  (clock,
weather, workplace switcher, window list, system monitor.  All of the regular
icons show up on my panel but instead of the applets I get a series of
overlapping windows on my desktop saying:  "The panel encountered a problem
while loading (applet name).  Delete this application from configuration?"

If I log out and log back in immediately, all of the applets load normally.

This only happens when logging in from my terminal.  I have never seen this when
logging into the server directly.  This didn't happen with this exact same setup
under Fedora Core 6.

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

How reproducible:
50% of the time

Steps to Reproduce:
1.Log in from LTSP terminal. No applets appear
2.Log out
3.Log in and applets appear as normal
Actual results:
The panel applets fail to load 50% of the time.

Expected results:
Panel applets should load.

Additional info:

Comment 1 John McBride 2007-06-29 05:50:15 UTC
I'm going to piggy back on this. I'm seeing an F7 problem with vncserver that is
very similar.

On FC6 I could startx and vncserver in pretty much any order and all was well.

Under F7 I see an oddity in that some panels widgets only survive as
"first instance".

Let the system be setup with /etc/sysconfig/vncservers -> 1:user 2:user.

Case 1 : vncserver before startx : The vnc clients have all widgets displayed as
expected whether or not user starts X. If user logs in, and starts X, two
configured widgets do not appear that should be present. Attempting to add the
two missing widgets to the panel fail. "vncserver wins".

Case 2 : startx first, then vncserver : The user desktop has all panels and
widgets displayed as configured. Now start vncserver. In this case, the vnc
connections do not show the widgets. "desktop wins".

So it looks like a "first instance wins" problem under F7. I tested this against
FC6 and all widgets are present under both scenarios.

The two widgets that appear in one place and not the other are Clock and Window

Comment 2 Frank Cox 2007-08-01 01:45:39 UTC
This bug can be consistently "fixed" by doing the following after logging in:

killall bonobo-activation-server
killall gnome-panel

I don't know if that means that this bug should be filed against
bonobo-activation-server ?

Comment 3 David Timms 2007-08-01 14:21:24 UTC
(In reply to comment #1)
> expected whether or not user starts X. If user logs in, and starts X, two
> configured widgets do not appear that should be present. Attempting to add the
> two missing widgets to the panel fail. "vncserver wins".
I concur that it is repeatable using this method; the actual apps missing are
desktop switcher, clock, volume. Trying to readd sort of fails:
- doesn't make a difference for the second logged in user
- but logout, login again as the only active user and I see two instances of
each applet that was missing, and that I re-added.

Does it only happen when the same user is logged in twice ? {eg two user1
vncservers running / one user1 on the console {gui} and one or more user1 
vncservers started}

Does the LTSP terminal use vnc ?

Comment 4 John McBride 2007-08-02 07:00:03 UTC
1) Does it only happen when the same user is logged in twice ? {eg two user1
vncservers running / one user1 on the console {gui} and one or more user1
vncservers started}

Yes. If a single instance of any X exists for the user, it is, by definition,
the "first in", so it wins.

The second (or more) instances have the missing/broken widgets.

I tried two tests tonight, both using non-console vncservers.

Test 1 : your specific case of two vncserver instances as opposed to one on the
console console/one vncserver as follows :

a) as root : added a user1 system account, and configured two vncservers in
/etc/sysconfig/vncservers (2:user1 and 3:user1)

b) as root : copied /home/user1/.vnc directory into place with the xstartup file
and vnc passwd present. Chmod to user1.user1 by root. The user1 account was
never logged in in any way.

c) with another user running X on the console, opened xterm as root and started
vncserver. The usual xauth timeout appears, which is a long-term expected issue.

Results :
Using vncviewer against localhost:1 fails, 111, connection refused, as it is not
configured. Expected.

Using vncserver against localhost:2 succeeds, and all panel widgets are correct.

Using vncserver against localhost:3 succeeds, however several panel widgets are
broken or not present. This is the bug.

Logging out of both vncviewers and then logging into :3 still shows the panel
widgets broken. The second Xvnc session is clearly borked.

Logging out of both vncviewers, killing the Xvnc for :2 via the command line,
then logging back into :3 shows 8 dialog boxes have popped up, with strings like
"Widget has quit unexpectedly. If you reload a panel object, it will
automatically be added back to the panel", with button choices of "Don't Reload"
or "Reload".

The widgets named in the dialogs are :
Window List
Volume Control
Notification Area
Show Desktop
Workspace Switcher
User Switcher

This does not happen in FC6.

Test 2 : your specific case of two vncserver instances, this time without X
running on the machine (runlevel 3, ps shows no X or widgets), and using
"Chicken VNC" on my mac osx tiger to login, and not having the user1 account
logged in in any way. Basic configuration is the same as the previous case.

a) Chicken VNC seems to allow only one vnc client session. Logging into :1, as
usual, gets connection refused as there is no server configured.

b) Logging into :2 shows the expected desktop with all widgets properly displayed.

c) Logging into :3, oddly enough, gives a greeter login for user1. Huh. Anyway,
the panel widgets are broken as per the bug report.

I don't know if LTSP uses vncserver. I know the gnome remote desktop tool works
correctly, and I have heard it is partially based on the vnc protocol. Also
multiple XDMCP sessions work correctly, no missing widgets on the panels.

Thank you for taking the time to look at this. Will test anything you can come
up with.


Comment 5 John McBride 2007-08-03 06:03:09 UTC

XDMCP sessions do it, too. I logged in two (X -query) sessions into a headless
machine (gdm --no-console running) as user1, the second session one warned me
user1 was already logged in, logged in anyway, and the applets were missing in
the second session.

The gnome remote desktop doesn't show the problem as is a mirror of the current


Comment 6 Will Starck 2007-08-03 22:41:28 UTC
I have this exact same problem, which I filed as bug 243670, accordingly 243670 
is a duplicate of this bug. 

This report better describes the problem, i.e, "first X-session wins" and all 
others will have broken applets.

This is what it looks like:


Comment 7 Ray Strode [halfline] 2007-08-04 19:00:14 UTC
*** Bug 243670 has been marked as a duplicate of this bug. ***

Comment 8 Valent Turkovic 2007-08-06 07:27:23 UTC
I had this happen a few times under Fedora Core 6... just using gnome as a
single user. I haven't seen this in F7 yet (and hope I won't)...

Comment 9 Will Starck 2007-08-08 01:15:26 UTC
I can *also* confirm that this bug can be fixed by killing the bonobo-
activation-server, logging out, and then logging back in

Comment 10 Frank Cox 2007-08-08 01:25:23 UTC
What if you "killall gnome-panel" immediately after killing
bonobo-activation-server?  I don't need to log out and log back in to fix it; I
can just killall gnome-panel.

Comment 11 John McBride 2007-08-08 17:03:13 UTC
Let three machines be M1, M2, M3.

M1 : configure gdm with gdmsetup, go into runlevel 3, run gdm --no-console

M2, M3 : runlevel 3, then "X -query ip-address-of-M1" log both in as user1.

result : as expected, first in has good widgets, later machine has broken panel
widgets. 2nd in requires "log in anyway".

1) log out M2 and M3 to greeter.
2) log in M2 w/ good panel and widgets
3) killall bonobo-activation-server on M1 and verify it is gone
4) log in M3

Widgets are good on both M2 and M3.

Killing bonobo-activation-server on M1 helps until gdm restarts it. Once b-a-s
is restarted by gdm the problem comes back, and the some things (like the
greeter on M2 and M3) start having issues too, like extended time to appear or

Killing all gnome-panel on M1, after M2 and M3 are logged in as user1, appears
to cause the bug on both machines; they both popup with "encountered a problem
while loading...applet" dialogs and broken panel widgets.


Comment 12 Ray Strode [halfline] 2007-08-08 17:14:15 UTC
Note, we don't currently support the same user being logged in more than once. 
A lot of things will break presently.

Frank, in your setup are you logging in with the same user more than once?

Comment 13 Will Starck 2007-08-08 17:18:58 UTC
(In reply to comment #10)
> What if you "killall gnome-panel" immediately after killing
> bonobo-activation-server?  I don't need to log out and log back in to fix it; 
> can just killall gnome-panel.

Yes, this works as well

Comment 14 Frank Cox 2007-08-08 17:30:07 UTC
I log in under one user name on my LTSP server, and under a different username
on my Neoware terminal that is attached to that LTSP server.

So there is only one login per username on this system.

The problem started when I upgraded this system from FC6 to F7.  Initially it
occurred on a 50% of the time basis, where I had to log in, log out, and then
log in again on my terminal in order to have the panel applets work.  Lately, it
started not working on a consistent basis where I would log in and log out and
log in again about ten or twelve times and the panel applets would never work. 
That is when I discovered that the "killall bonobo-activation-server" followed
by "killall gnome-panel" would make everything work properly again.  So I have
been doing that ever since, instead of trying to log out and log in again.

I now get the "The panel encountered a problem while loading (applet name). 
Delete this application from configuration?" error messages about 4 out of 5
attempts to log in on my terminal.

I deleted my terminal username and set up a new one from scratch about a week
ago, thinking that the problem might go away if I did that, but the problem has
continued with my new user setup as well.

This problem NEVER OCCURS when I log in on my main computer (the LTSP server).

Removing the Tomboy applet from my panel seemed to make the problem go away for
about a day but then the problem came back and I have not put Tomboy back.  That
may or may not be a coincidence.

Comment 15 Ray Strode [halfline] 2007-08-08 18:08:36 UTC
can you attach your .xsession-errors when it happens?

Comment 16 Frank Cox 2007-08-08 18:26:55 UTC
Created attachment 160925 [details]
.xsession-errors on panel applet load failure

Comment 17 John McBride 2007-08-09 05:40:04 UTC
> Note, we don't currently support the same user being
> logged in more than once. 
> A lot of things will break presently.

I've been using an array of vncserver displays against a single vnc user for
years without any problem. I guess I just got lucky?

Comment 18 David Wood 2007-08-15 10:45:45 UTC
This bug is hitting hard as I have a number of remote users who access a few
central machines via XDMCP.  The problem only seems to have been reported since
I applied various F7 updates but I don't know which one triggered it.

Comment 19 Larry Bartash 2007-09-06 23:38:57 UTC
I have the same problem on Fedora 7 with LTSP 4.2 only on the terminals. However
I have noticed that even when the user logs out there are two processes still
running on the host. See below: (ps aux | grep myuser)

myuser    6254  0.2  0.1  38540  2628 ?        Ssl  18:19   0:00
/usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=16
myuser    6297  0.0  0.0   2504  1056 ?        S    18:19   0:00

If I do nothing about this and they log back in, then the user is hit with all
the  panel applet load failures. If I kill those processes first and then let
them log in; the panel applets load fine.

Comment 20 Rasmus Ory Nielsen 2007-09-19 18:15:04 UTC
I had the same problem after logging out locally and then logging in remotely
with Freenx.
F7 updated today.

Comment 21 Leigh L. Klotz, Jr. 2007-11-12 20:56:00 UTC
(In reply to comment #12)
> Note, we don't currently support the same user being logged in more than once. 
> A lot of things will break presently.

This is just really sad.  One of the advantages that X had over the VMS window
system from DEC originally was that VMS wouldn't let you log in twice.

Comment 22 Frank Cox 2007-11-16 19:38:06 UTC
This problem continues on Fedora 8.  After logging in on a terminal, then
logging out and logging back in, I get all of the previously mentioned "panel
applet failure to load" messages.  "killall bonobo-activation-server" followed
by "killall gnome-panel" causes the problem to go away and the panel applets to
load properly.

My "terminal user" (named terminal) is not logged in right now.  In fact, the
terminal is physically switched off.  However, running "ps -FA | grep terminal"
shows me this:

terminal 26006     1  0 52964  2752   0 11:18 ?        00:00:00
/usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=16

Shouldn't bonobo-activation-server go away when the user logs out?

Comment 23 Frank Cox 2007-11-16 19:40:28 UTC
oops -- I should have set the "hardware" flag to x86_64 and not ia64.  Sorry
about that.  I don't have an Itanium.

Comment 24 Larry Bartash 2007-11-23 14:47:07 UTC
OK on f8 (i386) with the latest gnome-applets-2.20.0-8.fc8
this update has corrected some of the applets, but not all.
At least TomboyApplet and FastUserSwitchApplet still have this problem as they
show the error loading dialog box. 

If I don't delete them, none of the applets show.

If I delete those two from the users configuration, the other applets appear
properly (GNOME_Wncklet_Factory, GNOME_Panel_TrashApplet_Factory,
GNOME_ClockApplet_Factory, GNOME_MixerApplet_Factory, and
This is repeatable (logging out and logging back in).

After deleting TomboyApplet and FastUserSwitchApplet and logging out there was still
myuser   22110  0.0  0.1  39828  2608 ?        Ssl  08:36   0:00
/usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=16

After killing that process and successive login/logout without those suspect
applets, bonobo-activation-server process does not persist after logout.

Comment 25 Bug Zapper 2008-11-26 07:22:06 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 to the applicable version.  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.

The process we are following is described here: 

Comment 26 Bug Zapper 2009-01-09 07:09:05 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.

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