Description of problem: A long running Xvnc is responsive, accepts connections, authenticates, and shows the initial desktop state. Pressing keys into an open gnome-terminal shows that vncviewer is not receiving screen updates. Version-Release number of selected component (if applicable): kernel-2.6.19-1.2895.fc6 * active kernel-2.6.20-1.2933.fc6 not yet booted! kernel-devel-2.6.19-1.2895.fc6 kernel-devel-2.6.20-1.2933.fc6 kernel-headers-2.6.20-1.2933.fc6 VMware-server-1.0.1-29996 VMware-server-console-1.0.1-29996 vnc-4.1.2-9.fc6 vnc-server-4.1.2-9.fc6 xorg-x11-server-Xorg-1.1.1-47.5.fc6 How reproducible: Have seen previously on a different FC3 that was up a long time. May only happen when uptime is large: 13:51:18 up 71 days, 2:13, 4 users, load average: 0.06, 0.09, 0.02 Steps to Reproduce: 1. x86_64 AMD AM2, 2GB ram, vmware-server running 2x 512MB ram vm's 2. 2007-01-26 yum update, rebooted. 3. 2007-03-23 yum update, not rebooted. 4. vnc clients continue to connect and receive screen changes OK. 5. 2007-04-07 yum update, not rebooted. 6. from fc6 update machine, connect to the vncserver. Actual results: vncviewer across ssh stops receiving screen updates. Moving the mouse, causes the screen to refresh. Moving the mouse continuously keeps the local vncviewer screen live to the vncserver. Expected results: Normal VNC operation, ie screen getting update as it changes (rather than when you move the mouse). Additional info: Tried from another machine that I was vnced to, same result (this normally works also). No errors logged to /var/log/messages on either machine. ps aux|grep -E 'X|vnc' root 2706 0.0 0.0 65044 476 ? Ss Jan26 0:00 /bin/sh /etc/X11/prefdm -nodaemon davidt 2959 0.0 1.5 62540 30232 ? S Jan26 87:48 Xvnc :1 -desktop davidtdesktop:1 (davidt) -httpd /usr/share/vnc/classes -auth /home/davidt/.Xauthority -geometry 1024x768 -depth 16 -rfbwait 30000 -rfbauth /home/davidt/.vnc/passwd -rfbport 5901 -pn davidt 2980 0.0 0.0 31100 420 ? Ss Jan26 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients davidt 2983 0.0 0.0 15132 364 ? S Jan26 0:00 /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients root 4719 0.0 0.0 60280 736 pts/4 R+ 14:18 0:00 grep -E X|vnc root 23961 0.0 0.1 77588 2796 tty10 Ss+ Mar23 0:00 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt10 --- top - 14:24:16 up 71 days, 2:46, 4 users, load average: 0.04, 0.06, 0.02 Tasks: 136 total, 1 running, 135 sleeping, 0 stopped, 0 zombie Cpu(s): 0.4%us, 0.7%sy, 0.0%ni, 98.5%id, 0.0%wa, 0.4%hi, 0.0%si, 0.0%st Mem: 1989348k total, 1599772k used, 389576k free, 79860k buffers Swap: 517380k total, 15656k used, 501724k free, 1100724k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26781 davidt 5 -10 677m 495m 478m S 1 25.5 98:18.08 vmware-vmx 2959 davidt 15 0 62540 29m 2528 S 0 1.5 87:49.28 Xvnc --- Around the time that this began, I had been trying to get system-config-date to pickup ntp time, and also performed a yum update. --- Occurs on all elements eg: - locked screensaver=black dialog - gnome-menu: click, wait not result, move mouse, menu appears. - gnome-terminal: top -d 1 updates only when mouse moved/moving.
Created attachment 151907 [details] /var/log/yum.log listing packages that changed Apr 7 11:00 ps. I had a bit of a go at getting more info with gdb, but no luck. I can leave the vncserver running a few more days if someone has some ideas about capturing further relevant information from the faulting system. If not, I expect that I'll vncserver -kill :1 and restart it vncserver :1, and see if that is enough to solve it. A hunch tells me it's due to updating some package on the system. If so, perhaps the package needs to tell vncserver to restart ?
Had another idea, started another vnc, without rebooting or stopping the problematic one: # vncserver :2 {root} $ vncserver :3 {same user} Both the newly started sessions operate normally when viewed from vncviewer. What would that suggest ?
I don't have any ideas what package could cause this problem :( But restarting Xvnc is really bad idea. You could updating packages and doing some important work through Xvnc and restart is bad idea. Looks that this problem will be never fixed. Thanks for your report, closing. Regards, -A-