Bug 245525

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

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 ?

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

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

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 :
Trash
Window List
Volume Control
Notification Area
Show Desktop
Workspace Switcher
User Switcher
Clock

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.

---
John

Clarification/Correction:
-------------------------

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

---
John

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:

http://www.tigernet.net/badgnome.jpg

*** Bug 243670 has been marked as a duplicate of this bug. ***

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

I can *also* confirm that this bug can be fixed by killing the bonobo-
activation-server, logging out, and then logging back in

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.

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

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.

---
John

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?

(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; 
I
> can just killall gnome-panel.

Yes, this works as well

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.

can you attach your .xsession-errors when it happens?

Created attachment 160925 [details]
.xsession-errors on panel applet load failure

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

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.

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
/usr/libexec/gam_server

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.

I had the same problem after logging out locally and then logging in remotely
with Freenx.
F7 updated today.

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

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?

oops -- I should have set the "hardware" flag to x86_64 and not ia64.  Sorry
about that.  I don't have an Itanium.

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

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.