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 and kvnc 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