While starting VNC session in Solaris 10 I am getting below error:
A VNC server is already running as :0
root 19790 15407 0 05:55:22 pts/3 0:00 grep -i vnc #
however there is no sessions running at :0. I am not very sure if somewhere we have to define :0 port or not.
For me, as suggested in the comments, the solution was to delete some temporary files from a previous run:
rm -f /tmp/.X0-lock
rm -f /tmp/.X11-unix/X0
After a lot of efforts I found removing .vnc folder(inside $Home) resolves the issue. .VNC folder is created every time you run the vncserver. This folder has a file that has a process Id of vnc to kill. In case the vncserver process hangs and doesn't even shows in ps -ef command, remove the .vnc folder, after that vncserver will be able to create new .vnc folder and kill the existing process.
It is possible that display :0 is locked by a previous failed\crashed vnc session.
You can kill the :0 session by running:
vncserver -kill :0
From vncserver man page:
-kill :display# This kills a VNC desktop previously started with vncserver. It does this by killing the Xvnc process, whose process ID is stored in the file "$HOME/.vnc/host:display#.pid". The -kill option ignores anything preceding the first colon (":") in the display argument. Thus, you can invoke "vncserver -kill $DISPLAY", for example at the end of your xstartup file after a particular application exits.
You can also check if the lock files are still there. here is the relevant files, from the man page:
FILES Several VNC-related files are found in the directory $HOME/.vnc:
$HOME/.vnc/xstartup A shell script specifying X applications to be run when a VNC desktop is started. If this file does not exist, then vncserver will create a default xstartup script which attempts to launch your chosen window manager. $HOME/.vnc/passwd The VNC password file. $HOME/.vnc/host:display#.log The log file for Xvnc and applications started in xstartup. $HOME/.vnc/host:display#.pid Identifies the Xvnc process ID, used by the -kill option.
For example, I started vncserver with :22 and then killed it (twice):
[raamee 25 0 ~]$ vncserver :22
New 'myhost:22 (raamee)' desktop is myhost:22
Starting applications specified in /home/raamee/.vnc/xstartup
Log file is /home/raamee/.vnc/myhost:22.log
[raamee 26 0 ~]$ vncserver -kill :22
Killing Xvnc process ID 22733
[raamee 27 0 ~]$ vncserver -kill :22
Can't find file /home/raamee/.vnc/myhost:22.pid
You'll have to kill the Xvnc process manually
Do
sudo netstat -anp
you will find that xinetd is holding the ports.
tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 531/xinetd
tcp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN 531/xinetd
shown above as pid 531
kill 531
and you are good to go. I 'fixed' mine by editing /etc/xinetd.d/Xvnc to look like this
service Xvnc
{
type = UNLISTED
disable = yes
socket_type = stream
protocol = tcp
wait = yes
user = root
server = /usr/bin/Xvnc
server_args = -inetd :1 -query localhost -geometry 1920x1080 -depth 24 -once -fp /usr/share/fonts/X11/misc -DisconnectClients=0 -NeverShared passwordFile=/root/.vncpasswd -extension XFIXES
port = 5905
}
So I ran this command >
lsof | grep x11
which gave me the port occupied by x11 process, when I killed those, my vnc port got free and I could start the new vnc session on the same.
(many years later, for people arriving through Google Airlines)
I just suffered a similar problem. An unrelated service was listening on port 6001 (vs 5901) that according to /etc/services corresponds to x11.
Moving the service to another port fixed the issue.
Aside from deleting tmp files, you might want to run
sudo netstat -anp | grep 5901
to see if any other process is blocking port 5901, for me, it's been used by qemu-system-x8, guess I'll have to start my session from '2'.
