J'ai le problème suivant : De nombreux utilisateurs créent des sessions VNC et les oublient ensuite. Au bout d'un certain temps, ces sessions plantent et commencent à consommer environ 100 % d'énergie. Quelqu'un doit alors les tuer manuellement.
Ma question est la suivante : existe-t-il un moyen de trouver ces sessions plantées et de les tuer automatiquement ?
Vos utilisateurs doivent-ils se reconnecter aux sessions ou leurs sessions doivent-elles se terminer lorsqu'ils se déconnectent ? S'ils n'ont pas besoin de se reconnecter, la réponse de Jeff McCune est une bonne approche. S'ils ont besoin de se reconnecter, je suggère de rechercher dans la sortie de 'netstat -an' tous les ports VNC qui écoutent mais n'ont pas de connexions établies. Ensuite, pour ces ports, vous pouvez rechercher dans la sortie de 'ps ax' l'ID du processus du numéro d'écran VNC correspondant et le regrouper dans une liste. Enfin, vous pouvez parcourir la liste et tuer ces PIDs.
Je ne suis pas certain qu'il soit possible de construire une solution automatisée qui ne repose pas sur l'heuristique et l'observation/parsage de divers morceaux de /proc et /sys.
Je/nous utilisons RealVNC (Xvnc) sur RHEL4 et la version gratuite de RealVNC a tendance à faire ce que vous décrivez (je n'ai pas encore vu la version commerciale/payante de RealVNC faire cela). Il semble (je n'ai rien de mieux que des anecdotes pour étayer cela) que c'est pour nous une interaction entre (l'ancien) gnome/metacity et Xvnc qui déclenche parfois cela, car j'ai convaincu certains utilisateurs de passer à XFCE et ils n'ont pas eu de problème depuis.
Ce que je fais actuellement (la solution la plus rapide) est, par la magie de Python, de rechercher les processus avec /proc/<pid>/exe pointant vers le binaire Xvnc, d'analyser les fichiers journaux pointés par fd 2 par les processus pour déterminer depuis combien de temps l'utilisateur n'a pas utilisé la session (et dans le cas d'un fichier journal supprimé, de supposer le démarrage du processus, et de le notifier comme tel), puis de tuer les processus Xvnc qui n'ont pas été utilisés pendant quelques semaines.
Ce que j'envisage de faire, c'est d'utiliser un peu plus d'états, en échantillonnant de temps en temps /proc/<pid>/stat pour rechercher les processus Xvnc qui maintiennent une augmentation de l'utime proche de l'heure du mur sur une longue période de temps et de l'utiliser comme heuristique à la place.
Idéalement, j'aimerais trouver la cause sous-jacente de ce problème, mais faute de temps (et de volonté) pour me plonger dans les entrailles de Xvnc, je ne fais actuellement que soulager les symptômes.
Quitter ou arrêter une session VNC 1) Pour quitter votre session VNC, il suffit de tuer la fenêtre du client sur votre machine locale. Cela mettra fin à votre connexion au serveur VNC mais laissera votre session VNC intacte afin que vous puissiez vous y connecter ultérieurement.
2.pour terminer votre session de serveur VNC, connectez-vous à melodic et lancez la commande suivante : runvnc -kill :xx où xx est le numéro de votre écran.
Si vous avez oublié votre numéro d'affichage (ou pour vérifier le nombre de sessions de serveur VNC que vous utilisez), tapez ps ax | grep Xvnc La commande 'ps' va générer une liste des processus que vous exécutez. Le signe '|' va "pipeer" la sortie de la commande ps vers la commande 'grep' qui va rechercher et afficher les lignes contenant l'expression "Xvnc". Sur ces lignes, vous verrez Xvnc suivi de :x, où x est votre numéro d'affichage. Xvnc est le processus unix qui exécute la session du serveur VNC. Maintenant que vous avez le numéro d'affichage, vous pouvez soit tuer votre session Xvnc, soit vous y connecter à partir de votre client VNC.
Vous pouvez encore réduire la liste des processus Xvnc pour n'afficher que le vôtre en tapant
ps ax | grep Xvnc | grep
où est votre identifiant de connexion.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
