Hi,
I've set up a shared Linux machine (cvshost) on the corporate LAN. It stays up continuously. Access from Windows XP desktops, all on the same LAN, is through VNC. It's not tunneled.
Each worker has his own account on cvshost, and his own display number from the vncserver.
The problem: after a few hours, vncserver will drop out for some displays.
Symptom: e.g. user6 is able to access normally (at cvshost:6) for "a while", and then at some point when he tries to reconnect his client says "failed to connect to server." Running
ps confirms the Xvnc process is gone (though others may be up). Looking in /home/user6/.vnc/ shows nothing obvious in the log. /var/log/messages doesn't show anything either.
Each account was created with "useradd -m". They all have vncpasswd's.
Only workaround: do a
service vncserver restart.
There are also problems with lock files being left around, which I have to manually delete before vncserver start succeeds. I made a script to clean these up:
Code:
#!/usr/bin/perl
# Code to clean up after vncserver, which can hose itself
# by complaining about leftover lock files.
#
# This future code will help "unfsck" the vncserver state
# by removing those files.
#
`rm -rf /tmp/.X[2-7]-lock`;
`rm -rf /tmp/.X11-unix/X[2-7]`;
print "vnc server files are unfux0red.\n";
The user is leaving his Linux account logged in between sessions, and just exiting the VNC Viewer on Windows.
Anyone know what could cause Xvnc to just bail without saying why?
Here's supporting info:
Client: Windows XP, TightVNC Viewer 1.2.9
Server: Red Hat 9, kernel 2.4.20-8 (no patches), tightvnc-server-1.2.9-1 RPM
No changes to tightvnc configuration, other than
- chkconfig "on" for runlevels 2,3,5
- etc/sysconfig/vncservers list as below:
VNCSERVERS="2:user2 5:user5 6:user6 7:user7"
PS for normally running vnc setup:
Code:
root# ps -wef | grep vnc
504 9296 1 15 09:51 pts/0 00:09:35 Xvnc :2 -desktop X -httpd /usr/share/vnc/classes -auth /home/user2/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/user2/.vnc/passwd -rfbport 5902 -fp unix/:7100
user5 9316 1 2 09:51 pts/0 00:01:17 Xvnc :5 -desktop X -httpd /usr/share/vnc/classes -auth /home/user5/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/user5/.vnc/passwd -rfbport 5905 -fp unix/:7100
user6 9437 1 9 09:51 pts/0 00:05:54 Xvnc :6 -desktop X -httpd /usr/share/vnc/classes -auth /home/user6/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/user6/.vnc/passwd -rfbport 5906 -fp unix/:7100
user7 9470 1 22 09:51 pts/0 00:13:52 Xvnc :7 -desktop X -httpd /usr/share/vnc/classes -auth /home/user7/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/user7/.vnc/passwd -rfbport 5907 -fp unix/:7100
User6's vnc xstartup: same vanilla setup as everyone else's:
root# cat /home/user6/.vnc/xstartup
Code:
#!/bin/sh
# Red Hat Linux VNC session startup script
exec /etc/X11/xinit/xinitrc
vncpasswd is set.
iptables -L -n -v shows nothing rejected at firewall.
Normal log file looks like this:
Code:
root# cat cvshost\:6.log
14/10/05 09:51:38 Xvnc version 3.3.tight1.2.9
14/10/05 09:51:38 Copyright (C) 1999 AT&T Laboratories Cambridge.
14/10/05 09:51:38 Copyright (C) 2000-2002 Constantin Kaplinsky.
14/10/05 09:51:38 All Rights Reserved.
14/10/05 09:51:38 Desktop name 'X' (cvshost:6)
14/10/05 09:51:38 Protocol version supported 3.3
14/10/05 09:51:38 Listening for VNC connections on TCP port 5906
14/10/05 09:51:38 Listening for HTTP connections on TCP port 5806
_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
SESSION_MANAGER=local/cvshost:/tmp/.ICE-unix/9441
Xlib: extension "RENDER" missing on display ":6.0".
Xlib: extension "RENDER" missing on display ":6.0".
Xlib: extension "RENDER" missing on display ":6.0".
Xlib: extension "RENDER" missing on display ":6.0".
14/10/05 09:52:35 Got connection from client 192.168.1.25
14/10/05 09:52:35 Protocol version 3.5
14/10/05 09:52:35 Ignoring minor version mismatch
14/10/05 09:52:36 Client 192.168.1.25 gone
14/10/05 09:52:36 Statistics:
14/10/05 09:52:36 framebuffer updates 0, rectangles 0, bytes 0
14/10/05 09:52:47 Got connection from client 192.168.1.121
14/10/05 09:52:47 Protocol version 3.5
14/10/05 09:52:47 Ignoring minor version mismatch
14/10/05 09:52:51 Full-control authentication passed by 192.168.1.121
14/10/05 09:52:51 Pixel format for client 192.168.1.121:
14/10/05 09:52:51 32 bpp, depth 24, little endian
14/10/05 09:52:51 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
14/10/05 09:52:51 no translation needed
14/10/05 09:52:51 Using tight encoding for client 192.168.1.121
14/10/05 09:52:51 rfbProcessClientNormalMessage: ignoring unknown encoding 8
14/10/05 09:52:51 Enabling X-style cursor updates for client 192.168.1.121
14/10/05 09:52:51 Enabling cursor position updates for client 192.168.1.121
14/10/05 09:52:51 Using image quality level 6 for client 192.168.1.121
14/10/05 09:52:51 Enabling LastRect protocol extension for client 192.168.1.121
14/10/05 09:52:51 rfbProcessClientNormalMessage: ignoring unknown encoding -223
(nautilus:9490): Eel-WARNING **: emit_event() returning FALSE!
For a log file after crash, I have to wait until this happens again.
I just fixed the /tmp/.ICE-unix permissions problem (owner, group were set to my non-root account). Would that have anything to do with it?
Thanks!