Xvnc4server creates two (2) lock-files in the /tmp directory when it starts up.
If the VNC server shuts down normally (e.g. with vncserver -kill :$NN (where $NN is the VNC display port number), these files are removed.
Xvnc4servev checks for the existence of these files on start-up, and exits with an error message if either exists.
Debian Linux Xvnc4server creates lockfiles in /tmp/. The lock-files are:
/tmp/X{nn}-lock/tmp/.X11-unix/X{nn}
where {nn} is the port number of the display. Note that these files are hidden, and that the naming can be confusing if the VNC server in question was started on display port :11 (since 11 is also the version part of X11, and the : is dropped from the display spec when the file name is constructed by xvncserver at startup.
Also: while VNC is running there may be other user-owned lock-files in /tmp that appear during VNC server operation. The ones listed here are the ones controlled by the VNC server itself.
If Xvnc4server has died and left these lock-files in place, VNC connection attempts (via SSH tunnel) will report network connection failed errors on the client-side, and open failed: connect failed: Connection refused channel errors on server-side console during connection attempts.
This condition can be confirmed using the following command from the shell prompt on the server:
ps ax | grep `cat /tmp/.X$NN-lock`
Where $NN is the number of the display you're looking for.
If the command returns a process table entry for a running VNC server at with the PID stored in the lockfile, then there is some other problem - if the command returns nothing, or only the proc table entry for e.g. the grep process itself, then the lockfiles may be safely removed, and the VNC server for the port restarted.
