Bug 426249 - Gnome applets not displayed
Summary: Gnome applets not displayed
Alias: None
Product: Fedora
Classification: Fedora
Component: vnc
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-19 16:14 UTC by Patrick Monnerat
Modified: 2013-04-30 23:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-12-02 18:15:54 UTC
Type: ---

Attachments (Terms of Use)

Description Patrick Monnerat 2007-12-19 16:14:42 UTC
Description of problem:
When starting a vnc server with a gnome session, applets sometimes does not 
appear on the panel bars.

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

How reproducible:
Seems random. Always OK when starting server at first after system boot. The 
problem MAY occur when stopping it and restarting it.

Steps to Reproduce:
1. Start a vnc server, then stop it.
2. Start vnc server, connect to it with a client.
3. If applets (like volume control, etc) does not appear on panel(s), you've 
got it.
4. Else stop the server and restart at 2.

Actual results:
Only shortcut icons appear on panel bars. Even minimized windows are not 

Expected results:
A fully operational gnome panel.

Additional info:
May occur even when no gnome session active on the console.

Might be a gnome-xxx package problem. But it occurs only with vnc: thus it 
might be a vnc configuration bug. Please reassign if needed.

Comment 1 Adam Tkac 2007-12-19 17:22:15 UTC
Could you please tell me if you're using gnome session on multiple servers? (for
example you run standard gnome session on :0 and you try start next gnome
session through Xvnc on :1)

Comment 2 Patrick Monnerat 2007-12-19 18:49:17 UTC
I've add the problem in both cases.
For example, gdm expects login on :0 (so no session is started yet) and the 
single active session runs under Xvnc.
I generally start Xvnc dynamically (via xinetd) with the following parameters:
-inetd -once -query localhost -geometry 1024x768 -dpi 100 -depth 24 -
securitytypes=none -render
And XDMCP enabled in gdm

Comment 3 Adam Tkac 2007-12-20 14:37:34 UTC
gnome is not able to run on multiple servers. There's already bug for that issue
(#243933). Problem may be also related to bad font configuration in Xvnc. Could
you please test upcomming vnc and tell me if problem still exists?

Regards, Adam

Comment 4 Patrick Monnerat 2007-12-20 15:03:09 UTC
Still same problem with 4.1.2-23.1.fc8 downloaded from link above.
Test method is starting Xvnc with xinetd with same parameters as above.
Bug occurrence still looks random.
Thanks for trying

Comment 5 Vadim Nasardinov 2008-03-17 21:15:39 UTC
Grasping at straws here...

Patrick, do you run your Gnome under VNC with a different resolution
than you run your Gnome sessions on the console?

The reason I ask is because I have the same problem and the resolution
mismatch is the only peculiar thing about my setup, as far as I can

In my case, both the target machine (call it "work") and the client
machine (call it "home") are running F7. On my "work" machine, I have:

 | $ rpm -qa 'vnc*'
 | vnc-libs-4.1.2-19.fc7
 | vnc-server-4.1.2-19.fc7
 | vnc-4.1.2-19.fc7

When I'm physically present at my "work" machine, I run X on a
1600x1200 display.  When I vnc into my "work" machine from my "home"
machine, I use a different resolution, because my "home" monitor is
not as fancy.  On my "work" machine, I have:

 |$ grep -vE '^#' /etc/sysconfig/vncservers | cat -s
 |VNCSERVERARGS[1]="-geometry 1280x1024"

Also on the "work" machine:

 | $ grep -vE '^#' ~/.vnc/xstartup | awk '/[^ ]/ {print $0}'
 | exec /etc/X11/xinit/xinitrc
 | [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
 | [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
 | xsetroot -solid grey
 | vncconfig -iconic &
 | xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
 | twm &

Note that I start my VNC server with
  -geometry 1280x1024
even though my X server is normally configured to run with 1600x1200

Comment 6 Patrick Monnerat 2008-03-18 09:50:38 UTC
The main display is at 1024x768, but is almost never used (this is a 19" server)
The VNC session is generally at 1152x864. But I also had the problem with a 
1024x768 session. The client is W$ RealVnc 4.1.2. This is the most used 
configuration, but other combinations of client/server/resolutions cause the 
same problem too, providing the server runs on F8. FC6 was OK, I never tested 

However, with an up-to-date F8 (2008-03-18), the problem seems to occur much 
less frequently: although unidentified, I may think today the problem is not 

Comment 7 Bug Zapper 2008-11-26 09:04:43 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 8 Patrick Monnerat 2008-12-02 18:15:54 UTC
Cannot reproduce under F10. Seems to be fixed. Closing bug.

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