VNC connection keeps dropping

[stasJohn]

Hello

I'm running a Fedora Core 2 box. The vnc service starts up at boot and initializes three vnc servers.

from /etc/sysconfig/vncservers

VNCSERVERS="1:user1 2:user2 3:user3"

Each user does have an xstartup file in their home folder (and passwords were created for each user).

from /home/user/.vnc/xstartup

#!/bin/sh
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

Every few days or so, the connection is lost. That is, I am unable to connect to the linux box through the VNC service. (Note, we are using TightVNC on winXP home)

Sometimes it happens to all three users, sometimes its just happens to one user. I generally have to restart the system to bring it back.

Any ideas why this is happening? Fixes?

thanks in advance.

 

[pansophic]

First, please don't reboot the computer to fix this. That is a Windowsism. You can restart that service by typing "/etc/rc.d/init.d/vnc restart" as root. You may also be able to fix it by doing "ps waxu |grep vnc" and then "kill -HUP <process_id_from_ps>"

A brute force fix would be to issue the VNC restart as a cron job, but that is really a nasty way to fix it. It addresses the symptoms, not the problem. It will also knock off anyone who happens to be logged in.

Do you have any idea why the connection is dropping? Have you run tcpdump or looked at the logs "less /var/log/messages" to figure out why the system thinks that the connection is dropping?

It sounds as if you are having a TCP connection timeout, but the process that owns that connection is never dying. Therefore, it never answers a new incoming request.

Try running "netstat | grep -i vnc" and/or "lsof -i | grep -i vnc" and posting the results after a connection drop, before restarting the service. Make sure to sanitize any resolvable IP addresses before posting.


pansophic

 

[stasJohn]

thanks for the information.

I don't have any idea why the connection is dropping. I'm a newbie, so I'm still learning how to diagnose linux problems.

I will post results from netstat the next time it goes down.

Question though, what do you mean by "Make sure to SANITIZE any resolvable IP addresses"?

thanks again.

 

[LawnBoy]

Don't post any real IP numbers on this public forum.

 

[stasJohn]

Ah, wow, I really should of been able to figure that out. haha

 

[stasJohn]

Try running "netstat | grep -i vnc" and/or "lsof -i | grep -i vnc" and posting the results after a connection drop

Running the above commands results in nothing. Nothing is displayed.

Looking through the system log, I don't see anything regarding vnc.

Further, when I try to restart the vnc server using

/etc/rc.d/init.d/vncserver restart

I get error messages telling me to remove the following files.

[pre]
/tmp/.X11-unix/X1
/tmp/.X2-lock
[/pre]

Then I get a message telling me a "pid" file cannot be found.

Manually killing the process doesn't really work either.

Running

ps waxu |grep vnc

shows
[pre]
user 21242 0.0 0.1 4692 592 pts/1 S 10:08 0:00 grep vncserv
[/pre]

I'm not sure which is the process id, so I tried

kill -HUP

with 21242, 4692 and 592, which gave me a "no such process" error message.


Not sure if I gave enough information, but is there some other way I can go about restarting the service without restarting. Or why my vnc keeps shutting down.

 

[pansophic]

It looks as if the entire process is dying, and in a heinous fashion. The lock files don't get removed, so it doesn't want to allow you to restart. You'd need to manually delete the lock files. A simple "rm /tmp/.X11-unix/X1 /tmp/.X2-lock" should solve the problem, and then you will want to issue the "start" option, rather than the "restart" option on the vncserver command.

You have the right idea with the kill command. 21242 is the process id in your example, for future reference. The reason that the command failed is that the process that was displayed was your grep. As soon as it exited, that PID no longer exists. You probably want to grep for just vnc. vncserver is a wrapper command that probably exits once Xvnc (the actual application) is running (I don't have vnc installed, so I can't confirm this).

Sorry about the misguidance, the TightVNC log is in ~/.vnc/<machine_name>:<display_number>.log not in /var/log/messages. The tilde '~' is the home directory of the user who launched the displays. In your case, that may be root "/root." If it isn't you might want to do a locate to find the logs. Try "locate <machine_name> | grep .log" to find the file(s). If the locate command tells you that there is no database, type "updatedb" as root and it will create the locate database (this may take some time depending on the number of files on your system).

Hopefully there is some information in the logs that will give us an idea why the vnc server is dying.


pansophic

 

[stasJohn]

Thanks pansophic

I found the log files, but I decided to erase them, so that the next time the process dies, it should be easier to find the appropriate error messages.

I will post any new information the next time the connection fails.

 

[stasJohn]

Long time in posting, but just wanted to offer closure. I just never had time to properly look at the log files. Just dealt with it by restarting when necessary.

Anywho, recently discovered yum, used it to upgrade everything on my linux distro and now vnc works wonderfully. Been running for a couple weeks now with no problems. So, I guess vnc needed an upgrade!

 

[pansophic]

Good deal. It is always nice when things work out for the best.


pansophic