VNC Troubleshooting
When experiencing trouble with a VNC session, here are the most important things to check:
Check responsiveness of display host via ping or top
Check responsiveness of VNC server via ping or top
Run xfix on VNC viewer (background menu: FVWM Utilities > Fix X server)
Restart VNC viewer
Restart VNC server
VNC session dies consistently after a set amount of time
Symptom
A user's VNC viewer is consistently dying after being up for a modest amount of time.
Problem
The "keep alive interval" on their firewall or local machine is killing the SSH tunnel over which the viewers data are sent.
Solution
In their ~/.ssh/config
file, add a ServerAliveInterval
. For example:
Host *
ServerAliveInterval 300
VNC session is slow or hung locally
Symptom
A VNC viewer running locally (displayed to a computer at Keck) is not responding.
Problem
Either the VNC viewer is hung, the VNC server is hung, or one of the computers is hung.
Solution
Open a new VNC viewer pointed to the same VNC server.
If the new viewer works well, then the problem is with the VNC viewer or the computer displaying the viewer. In this case, verify that the computer running the viewer is responsive, then kill and restart the viewer.
If the new viewer does not respond, then the problem may be with the VNC server or VNC host. Check that the corresponding VNC host (svncserver1 or svncserver2) is responsive, then kill and restart the VNC servers as follows:
Log into the VNC host under the account running the servers (usually a numbered observing account.
Kill and restart the servers with:
kvnc stop servers
andkvnc start servers
Verify that no errors occur during startup.
If the servers cannot start or the host is unresponsive, try instructions for rebooting hosts or instructions for switching hosts.
VNC session is slow or hung remotely 1
Symptom
A VNC viewer running remotely (displayed to a computer outside of Keck) is not responding.
Problem
Either the VNC viewer is hung, the VNC server is hung, the internet is down, or one of the computers is hung.
Solution
Use a (local) VNC viewer to connect with the same VNC server. If the local viewer is also hung, see solution above. If the local viewer works well, then the problem is not with the local VNC server; it is with an intermediate router or with the remote site.
VNC session is slow or hung remotely 2
Symptom
Although a remote site is equipped with an ISDN router to provide connectivity in case of Internet outages, the VNC viewers at the remote site are unresponsive.
Problem
The router needs to be activated or firewall re-authentication is required.
Solution
Have observer at remote site attempt to move the mouse in the VNC viewer and generate some X events. This should force the ISDN router to attempt a connection to Keck.
If the VNC viewer at the remote site remains unresponsive after 2 minutes, then the router may be unable to connect due to firewall block. In this case, force a firewall re-authentication by interrupting the kvncinst/kvnctel/kvncall script using Ctrl-C in the xterm window where the script was executed, and re-run the kvncinst/kvnctel/kvncall command. Within a few seconds, the VNC viewers should activate.
If the VNC viewers remain unresponsive, then the remote observer should contact their site support personnel to verify that the ISDN router is activated and functional. If the remote site is UC-affiliated, then Bob Kibrick of UCSC should be contacted to assist with troubleshooting. See ISDN Router Commands Diagnostics for further information.
VNC server host is hung
Symptom
VNC servers are hung or dead, even from Waimea.
Problem
The summit VNC server host is hung.
Solution
Verify that server is unresponsive by attempting to ping the host (svncserver1 for Keck I instruments and svncserver2 for Keck II)
If no response, have software personnel attempt to revive server machine. If this fails, see or instructions for switching hosts.
If the server can be revived, then run:
kvnc start servers
(or, from any instrument session's FVWM background menu, select VNC > Start VNC servers) to re-launch the servers.Connect to the servers in the customary way.
VNC full screen mode enabled
Symptom
VNC session for an account is set to full screen mode preventing navigation to other areas on the local desktop. You can't access the analysis sessions.
Problem
The default vnc session settings are corrupt, and need to be reset.
Solution
Login using the affected account to the HQ machine currently displaying the vncviewer.
Determine the process ids for the vnc sessions:
ps -deaf | grep control
ps -deaf | grep analysis
kill the vncviewer processes using your favorite kill command (kill -15 ?).
Navigate to the vnc config directory: cd /home/mosfire9/.vnc/config.d .
Delete the vncviewer file: rm vncviewer
Using the VNC launch widget, restart the viewers.
Unable to open new windows
Symptom
The user can move the mouse and type into existing windows in the VNC session, but is unable to bring up new windows.
Problem
The VNC server has lost its X authentication and is prevented from launching new windows on the server.
Solution
From the FVWM background menu, select
FVWM Utilities < Fix X Server
If this fails to fix the problem, try killing and restarting the VNC server.
Unable to type in any windows in VNC session
Symptom
The user can move the mouse in the VNC desktop but cannot type into windows running in the VNC desktop.
Problem
Either the keyboard is unplugegd or the VNC server is malfunctioning.
Solution
Test whether the keyboard is functional by having the user type in windows outside of VNC. If this fails, check connection to keyboard.
If keyboard is functional, then restart the VNC servers.
Wrong language in xterm
Symptom
Beeps are audible with some keystrokes. In an xterm, "Have a nice day!" is translated into some other language emphasizing umlauts (Old Norse?).
Problem
Something is goofy (or vikingy if you believe the Old Norse).
Solution
Inside the VNC session, run VNC -> fix display (xfix)
Ouside the VNC session, run VNC -> fix display (xfix)
Then restart the VNC viewer. Destroy the existing viewer (destroy or use a ctr^c in the xterm running the viewer. Then select from the local desktop menu for example k2AO VNC menu -> Start image quality viewer (left) or restart the viewer using the VNC desktop gui.
In an existing or new xterm, type something and see if it displays normally. If it is still failing, you are on your own as the above has worked so far.
See also: https://www.keck.hawaii.edu/realpublic/optics/trouble/aotrouble.html#LgsOps11