View Issue Details

IDProjectCategoryView StatusLast Update
0003796CentOS-5gnome-panelpublic2013-04-04 19:19
Reporterslawekg 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Product Version5.3 
Target VersionFixed in Version 
Summary0003796: Gnome panel hangs after a click on System menu.
DescriptionI am using Centos 5.3 over VNC.
VNC session hangs after a click on System menu in gnome panel. VNC session is back after killing gnome-panel process. Looks like gnome-panel hangs and VNC server waits forever for a response. After killing gnome-panel, system automatically starts new gnome-panel process and VNC session is enabled and works
correctly.
I do not know if this can be reproduced on a screen directly connected to the machine. (Do not have such screen).
Additional InformationLinux centos 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 20:23:34 EDT 2009 i686 i686 i386 GNU/Linux
TagsNo tags attached.

Activities

devzero

devzero

2009-12-31 19:25

reporter   ~0010658

Using CentOS 5.3, experienced exactly the same issue. Selecting the 'System' menu in gnome panel causes the whole VNC session to lock. Need to ssh into system, 'killall gnome-panel', which resets gnome-panel and all is well, until the 'System' menu item is selected again. I have not found anything else that locks the session.

The server hosting the VNC session was running in headless mode, where there was no monitor/keyboard/mouse attached. It wasn't set up as such in the BIOS on the server. Went into BIOS, set server to headless operation, VNC 'system' menu problem still there. Hooked up a monitor/keyboard/mouse, and the 'System' menu issue went away -- in both headless mode and without it.

Bottom line on this situation, or at least in what I am experiencing is that VNC sessions running on a server need to have a monitor connected in order to function properly.
tsymyn

tsymyn

2010-01-12 02:20

reporter   ~0010760

I'm getting the same behavior with CentOS 5.4. I'm not sure exactly when it started but it was after Christmas '09. I'm using freeNX for remote access.
olaf

olaf

2010-01-30 21:11

reporter   ~0010903

I have the same problem on CentOS 5.4 and vnc.
I have run strace, and gnome-panel hangs connecting /tmp/.gdm_socket

As I have no monitor connected to my VGA card (nv driver) the X fails to start:

30499 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon
30527 ? Sl 0:00 /usr/libexec/gdm-rh-security-token-helper
30590 ? Ss 0:00 /bin/sh /etc/gdm/XKeepsCrashing
30608 ? S 0:00 /usr/libexec/gdmopen -l /bin/sh -c /etc/gdm/XKeepsCrashing -noopen
30609 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen
30808 pts/11 S+ 0:00 grep gdm

I have found no way to disable EDID detection for nv driver (there is an option for this, but it works only with the proprietary nvidia driver)

I suppose gdm is in some state that causes the communication using the socket to hang.

So we have a several problems here:
1. gnome-panel shoudn't hang when using this socket
2. gdm is doing something nasty with this socket

The workarounds for this bug:
1. Go into runlevel 3, you need to start a fresh vncserver afterwards or new nx session
or
2. Connect a monitor to the computer and restart X
or
3. Setup X in a way that enables successful startup without monitor connected to the graphics card (impossible with the opensource nv driver AFAIK)

So, there is 100% bug in gnome-panel, the gdm should be fixed probably too.
Mykola

Mykola

2010-02-21 08:06

reporter   ~0011024

I have the same problem

restart gnome-panel task helps, but not always.
mlyndaker

mlyndaker

2010-04-09 19:45

reporter   ~0011138

I same problem where selecting the system menu in a vnc session would cause gnome-panel to become unresponsive and needed to be killed, but I modified my ~/.vnc/xstartup file and gnome-panel no longer freezes.

---The working xstartup file is below---
#!/bin/sh

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
OS=`uname -s`
if [ $OS = 'Linux' ]; then
  case "$WINDOWMANAGER" in
    *gnome*)
      if [ -e /etc/SuSE-release ]; then
        PATH=$PATH:/opt/gnome/bin
        export PATH
      fi
      ;;
  esac
fi
if [ -x /etc/X11/xinit/xinitrc ]; then
  exec /etc/X11/xinit/xinitrc
fi
if [ -f /etc/X11/xinit/xinitrc ]; then
  exec sh /etc/X11/xinit/xinitrc
fi
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
exec gnome-session &
Mykola

Mykola

2010-04-10 12:21

reporter   ~0011139

Hi,
Thank you very much for your update, but in case it's not working...
I still have the same problem even after I used your xstartup.
When I'm trying to click on System menu it hang immediately.

Regards,
Mykola Yemelyanenko
mlyndaker

mlyndaker

2010-04-10 15:04

reporter   ~0011140

I'm sorry, the problem persisted after I rebooted and I could not edit my reply.

What I ultimately ended up doing was changing the default runlevel of CentOS in /etc/inittab to 3. This prevents X11 from starting on the local display, but vncserver will still start normally.

---Section of /etc/inittab below---
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

This works for me as I'm building a headless system, but I do not have a general fix. I've installed Fedora on the same machine and did not have this problem, it seems to be a bug in CentOS specifically.

Best,
Matthew Lyndaker
cepheid

cepheid

2011-07-06 20:13

reporter   ~0012910

This problem persists with CentOS 5.6. When running a VNC session (via vncserver, the wrapper to Xvnc), attempting to access the System menu causes gnome-panel to hang completely. Only a "kill -HUP" command gets things going again.

In my case, the system cannot be set to run at runlevel 3, as console X access is needed.

Is there no solution for this horrendous, long-standing bug?

Thanks.
cepheid

cepheid

2011-08-12 16:44

reporter   ~0013112

It seems that this is an upstream bug and that changing runlevel is only coincidentally a workaround, but is not required in all cases. I am currently running Gnome via VNC on two RHEL 5.5 systems, but whose packages are not entirely identical. Both systems are at runlevel 5. However, I do NOT experience this bug on one system, while I do experience it on the other.

Thus, not only is this an upstream issue, but there appears to be some fix for it somewhere, somehow, because the problem doesn't exist on one system but does on the other.

Hopefully we can get this resolved; let me know if you need more info (e.g. RPM lists, etc.).
cepheid

cepheid

2011-08-12 17:28

reporter   ~0013113

Upstream bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=730378
rstal01

rstal01

2012-05-14 14:30

reporter   ~0015078

This is confirmed still an issue for CentOS 5.8 as of currently.
rnutick

rnutick

2012-06-29 21:14

reporter   ~0015350

I was having this problem and found that the system-config-* packages were not installed. I installed ALL of them using yum:

yum install system-config-*

After the installation (and a reboot) the system menu no longer caused VNC to hang.
itasoro

itasoro

2012-08-24 09:31

reporter   ~0015702

@rnutick
I don't think it works.i try it,but it doesn't work.
hastrup

hastrup

2012-09-25 20:25

reporter   ~0015823

I had the same issue but discovered that when I killed the gnome-panel and re-started it in a terminal session it would crash with a message saying something about the gnome power manager .... I removed the gnome-power-manager package (yum erase gnome-power-manager) and that did the trick :-) the system menu is working now ....
fmv123

fmv123

2013-04-04 19:19

reporter   ~0017085

I am running 5.9. Everything was working fine until I did an update. Now it hangs whenever I click on the System menu. I tried all of the suggested fixes above and then some. Nothing seems to fix it.

Issue History

Date Modified Username Field Change
2009-08-25 09:28 slawekg New Issue
2009-12-31 19:25 devzero Note Added: 0010658
2010-01-12 02:20 tsymyn Note Added: 0010760
2010-01-30 21:11 olaf Note Added: 0010903
2010-02-21 08:06 Mykola Note Added: 0011024
2010-04-09 19:45 mlyndaker Note Added: 0011138
2010-04-10 12:21 Mykola Note Added: 0011139
2010-04-10 15:04 mlyndaker Note Added: 0011140
2011-07-06 20:13 cepheid Note Added: 0012910
2011-08-12 16:44 cepheid Note Added: 0013112
2011-08-12 17:28 cepheid Note Added: 0013113
2012-05-14 14:30 rstal01 Note Added: 0015078
2012-06-29 21:14 rnutick Note Added: 0015350
2012-08-24 09:31 itasoro Note Added: 0015702
2012-09-25 20:25 hastrup Note Added: 0015823
2013-04-04 19:19 fmv123 Note Added: 0017085