Bug 243933 - setting vnc for gui login clobbers gnome task bar
setting vnc for gui login clobbers gnome task bar
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-panel (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-12 16:13 EDT by john terebey
Modified: 2009-07-05 05:50 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:34:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description john terebey 2007-06-12 16:13:33 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.

How reproducible:
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.
2.reboot
3.notice that minimize of app vanishes.
  
Actual results:


Expected results:
same behavior as fc6 and fc5. normal gnome gui for vnc login.

Additional info:
Comment 1 Adam Tkac 2007-06-13 07:13:48 EDT
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

Thanks, Adam
Comment 2 Nick Sharp 2007-09-05 21:06:24 EDT
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: 
Top:
Left hand side: 'f' Apps/Places/System then quickstart icons: browser, email
Right hand side: smart card manager, Power, updates, login name, clock, volume
Bottom:
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
desktop!!

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
Comment 3 P Jones 2007-09-06 11:19:43 EDT
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:
#unset SESSION_MANAGER
#exec /etc/X11/xinit/xinitrc

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

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.  
Comment 4 Nick Sharp 2007-09-07 02:02:11 EDT
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
SESSION_MANAGER=local/nfm.chn.xerox.com:/tmp/.ICE-unix/10736
Traceback (most recent call last):
  File "/usr/bin/puplet", line 371, in <module>
    main()
  File "/usr/bin/puplet", line 368, in main
    p.run()
  File "/usr/bin/puplet", line 355, in run
    self._getOnDbus()
  File "/usr/bin/puplet", line 229, in _getOnDbus
    "/Updatesd")
  File "/usr/lib/python2.5/site-packages/dbus/_dbus.py", line 410, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 230, in __init__
    _dbus_bindings.UInt32(0))
  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,
timeout)
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
Comment 5 Adam Tkac 2007-09-17 08:53:33 EDT
(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

Comment 6 Adam Tkac 2007-09-17 09:01:20 EDT
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
investigation.

Adam
Comment 7 Ray Strode [halfline] 2007-09-17 10:45:47 EDT
see bug 247329 for another case, where things fall over.  It's basically note
supported atm.
Comment 8 Bug Zapper 2008-05-14 09:02:44 EDT
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 9 Bug Zapper 2008-06-16 21:34:05 EDT
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 10 David Timms 2009-07-05 05:50:45 EDT
(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.

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