Red Hat Bugzilla – Bug 243933
setting vnc for gui login clobbers gnome task bar
Last modified: 2009-07-05 05:50:45 EDT
Description of problem:
seems if you set vnc for gui login (by uncommenting /root/.vnc/xstartup areas),
then an unfortunate thing occurs. if the system is rebooted, the gnome
information task bar is hosed. that is the one that holds the active app icon
when minimized. also holds the desktops.
anytime you min an app, it seems to go to the lower right of the window and vanish.
also, during the bootup a message pops up that X windows found a different
keyboard setting than expected.
Version-Release number of selected component (if applicable):
latest for fc7. both i386 and x64.
very. if xstartup comments in, no gui login for vnc. if out, then gui ok.
Steps to Reproduce:
1.edit /root/.vnc/xstartup for ok gui.
3.notice that minimize of app vanishes.
same behavior as fc6 and fc5. normal gnome gui for vnc login.
I'm not sure what exactly you're doing. You using vncserver like service? (you
edit /etc/sysconfig/vncservers) Also could you attach Xvnc log or screenshot of
corruption, please? When I run vncserver on my machine all works as expected
Googling shows that several other folk (+ me) are having panel trouble with VNC
under F7; here's some more detail about my encounters.
If I login first time to a user on a laptop install of F7, desktop has two panels:
Left hand side: 'f' Apps/Places/System then quickstart icons: browser, email
Right hand side: smart card manager, Power, updates, login name, clock, volume
LHS: show desktop
RHS: workspace switcher, trash
Now in a terminal window I run vncserver 4.1.18 and give a password. Then I
gedit ~/.vnc/xstartup to uncomment the unset and exec lines
Then I vncserver -kill :displaynumber and vncserver again with new xstartup.
Then from another machine I connect using VNC client (windows, free edition, 4.1.2).
The vnc session desktop's top panel lacks all the RHS items, and the bottom
panel has NO items at all. An attempt to 'add to panel' ON THE VNC desktop, in
some cases (eg connect to server) adds the chosen item to both the VNC and
laptop screen desktops, and in others (CPU freq mon) only to the laptop screen
All very confusing. If the vncserver is re-started with "-AlwaysShared" then
second and subsequent views of the desktop via vnc behave identically to the first.
This occurs to me: "Should a desktop brought up in the usual way on the hardware
itself be the same one that is viewed via one or more vnc clients?" I guess yes
Hope this helps
I can reproduce this too.
To explain, near the top of ~/.vnc/xstartup (which is copied into that directory
on the first run of vncserver) is these three lines:
# Uncomment the following two lines for normal desktop:
The concept is that by running xinitrc, you can get a new session just as if you
were logging in instead of a custom scripted one as you would get later in the
xstartup scripts. Instead, the gnome-panels I see have only the menus,
launchers, and drawers. It does not have any of the applets (including
notification area, workspace switcher, multiload-applet, window list, etc). A
screenshot of this would probably not help.
This seems to be a problem with bonobo-activation-server.
If I run "vncserver && vncviewer :1 ; killall Xvnc"Â¹ I see this problem.
Running "killall bonobo-activation-server ; vncserver && vncviewer :1 ; killall
Xvnc" does not see this problem, of course I have no idea what else will fail on
the original login.
Basically, bonobo seems to not have the ability to run on multiple displays at
This should also affect remote (XDMCP) sessions. To verify this, I enabled
remote sessions via gdmsetup, and then ran "Xephyr -query localhost :5 -screen
1024x768" and logged on; it showed the same symptom.
Â¹The killall is just to kill off (all) the vnc sessions so next time I'm running
it, the vnc session would be :1 again.
Immediately after starting vncserver, the log reads as follows below, and does
not look very healthy. Hope this helps.
Xvnc Free Edition 4.1.2
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Underlying X server release 10299902, The X.Org Foundation
Fri Sep 7 12:52:48 2007
vncext: VNC extension running!
vncext: Listening for VNC connections on port 5901
vncext: Listening for HTTP connections on port 5801
vncext: created VNC server for screen 0
localuser:root being added to access control list
Traceback (most recent call last):
File "/usr/bin/puplet", line 371, in <module>
File "/usr/bin/puplet", line 368, in main
File "/usr/bin/puplet", line 355, in run
File "/usr/bin/puplet", line 229, in _getOnDbus
File "/usr/lib/python2.5/site-packages/dbus/_dbus.py", line 410, in get_object
File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 230, in __init__
File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 169, in __call__
reply_message = self._connection.send_message_with_reply_and_block(message,
dbus.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name
edu.duke.linux.yum was not provided by any .service files
Unable to open desktop file
/usr/share/applications/openoffice.org-1.9-writer.desktop for panel launcher: No
such file or directory
Unable to open desktop file
/usr/share/applications/openoffice.org-1.9-impress.desktop for panel launcher:
No such file or directory
Unable to open desktop file
/usr/share/applications/openoffice.org-1.9-calc.desktop for panel launcher: No
such file or directory
** (gnome-panel:10816): WARNING **: Failed to authenticate with GDM
(In reply to comment #2)
> This occurs to me: "Should a desktop brought up in the usual way on the hardware
> itself be the same one that is viewed via one or more vnc clients?" I guess yes
If I understand correctly you want share your desktop. You will be interested in
vnc.so Xorg module
After investigation it seems that gnome can't run on multiple servers at same
time. I've tried to run gnome session simulateously inside Xvnc and in Xorg and
second session was always corrupted (so if I run Xorg and then Xvnc Xvnc's
session has problems and reversely). Reassigning to gnome developers for next
see bug 247329 for another case, where things fall over. It's basically note
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:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
(In reply to comment #0)
> information task bar is hosed. that is the one that holds the active app icon
> when minimized. also holds the desktops.
> anytime you min an app, it seems to go to the lower right of the window and vanish.
> also, during the bootup a message pops up that X windows found a different
> keyboard setting than expected.
john, I had a similar issue when I logged into the gnome gui twice (once via vnc and the other via the console). This is resolved in F10 with current updates.
If you are still interested in this bug, perhaps you could perform your original test with a current Fedora release. If it is resolved, IMHO, it would be worth updating the closed|wontfix status to closed|current release, and updating the version to the Fedora release you tested with.