I have following issue: Many users create VNC session and after that they forget about them. After some time these sessions crash and start to consume about 100% power. Then somebody has to manually kill them.
My question is, Is there some way to find those crashed sessions and kill them automatically?
you can set a cron job to run every x minutes running a script that essentially runs "ps aux | grep vnc", and for each instance, kill the pid if the proc util is over a certain threshold.
You could run the VNC sessions from xinetd, which will terminate the vncserver when the client disconnects. This has the drawback of not allowing users to close their viewer and re-connect later.
Do your users need to reconnect to the sessions or should their sessions end when they disconnect? If they don't need to reconnect, Jeff McCune's answer is a good approach. If they do need to reconnect, I would suggest searching the output of 'netstat -an' for any VNC ports that are listening but have no established connections. Then for those ports, you could grep the output of 'ps ax' for process ID of the matching VNC screen number and massage that into a list. Finally you would run through the list and kill off those PIDs.
I'm uncertain how feasible it is to construct an automated solution which doesn't have to rely on heuristics and observing/parsing various bits of /proc and /sys.
I/we use RealVNC (Xvnc) on RHEL4 and the free version of RealVNC tends to do as you describe (I haven't yet seen the commercial/paid RealVNC do this). It seems (I don't have anything better than anecdotes to support this) that it's for us is an interaction between (ancient) gnome/metacity and Xvnc that sometimes trigger this, as I convinced some users to switch to XFCE and they haven't since been troubled by this.
What I'm currently doing (the quick-and-dirty solution) is by the magic of python looking up processes with /proc/<pid>/exe pointing to the Xvnc binary, parsing the logfiles pointed to by fd 2 by the processes to determine how long it's been since the user actually used the session (and in the case of a deleted logfile, assume process start, and notify as such), and then kill off Xvnc processes that's been unused for a few weeks.
What I'm considering doing is doing this a bit more stateful, by occasionally sampling /proc/<pid>/stat to look for Xvnc processes which sustain an increase in utime close to wall time over a longer period of time and use that as my heuristic instead.
Ideally, I'd like to find the underlying cause of this, but the absence of time (and will) to dive into the guts of Xvnc, I'm currently just alleviating the symptoms.
Leaving or stopping a VNC session 1.To leave your VNC session, just kill the client window on your local machine. This will terminate your connection to the VNC server but will leave your VNC server session intact so that you can connect to it at a later time.
2.To terminate your VNC server session, login to melodic and issue the following command: runvnc -kill :xx where xx is your display number.
3.If you have forgotten what your display number is (or to check how many VNC server sessions you might be running), type ps ax | grep Xvnc The command 'ps' will generate a list of processes you are running. The '|' sign will "pipe" the output of the ps command to the 'grep' command which will search for and display those lines containing the expression "Xvnc". On those lines, you will see Xvnc followed by :x, where x is your display number. Xvnc is the unix process that runs the VNC server session. Now that you have the display number you can either kill your Xvnc session or connect to it from your VNC client.
You can further narrow the list of Xvnc process to show only yours by typing
ps ax | grep Xvnc | grep
where is your login ID.
