Bonjour,
 
j'ai un petit soucis chez un de mes clients, et j'aimerais avoir votre avis sur la question :
 
Mon client a un serveur HP fonctionnant sous HPUX11. Sur ce serveur un ERP tourne et des utilisateurs dont le poste est sous windows travaillent avec cet ERP à travers un emulateur PuTTY et/ou Reflexion.  Jusqu'ici tout va bien la solution est très stable et performante.  Mais j'ai qd meme un soucis : lorsqu'un utilisateur se déconnecte "à la barbare" (arret du pc, deconnexion du cable reseau...),   vis à vis de HPUX, je vois toujours cet utilisateur de connecté. C'est à dire qu'il a toujours un process ksh et son sous-process de connexion à la base de données. Cependant cet utilisateurs n'est plus réellement connecté.   Ma question est donc la suivante :
existe-t-il un moyen :
 
1) d'empecher cela  
2) depuis le serveur, de detecter ces connexions fantomes afin de pouvoir les killer via un script.
 
 
Merci d'avance,
Vegas.

heartbeat sur les connections, avec un ping par exemple. Si le heartbeat s'éteint, tu kille le process.
 
http://fr.wikipedia.org/wiki/Heartbeat_(programme) pour commencer
 
attend d'autres suggestions plus éclairées et/ou plus précises.

ok mais j'ai 800 users et je me vois pas pinguer à tout bout de champ 800 pc sur le Lan.  
De plus on peut imaginer qu'un utilisateur se deconnecte mal du système => sa session reste sur le HP Mais si l'utilisateur n'a pas eteind son PC alors le Heartbeat ne voit rien du tout (car on peut tjs pinguer le pc) et j'ai toujours une connexion "fantome"

un ping toutes les 60 secondes / user ou 120 secondes ca va pas tuer ton réseau...
sinon je comprend pas ton argument, car tu parlais d'éteindre le pc ou déco le cable, donc je vois pas dans quel cas l'utilisateur peut éteindre le pc sans fermer le programme.
sinon intéresse toi à la durée de vie des connections et la durée d'inactivité surtout.

on imagine que l'utilisateur via le gestionnaire de taches tue le process lié à son emulateur et là : son pc sera toujours allumé donc présent sur le réseau et vis à vis du système HP, je verrais toujours une session utilisateur alors que l'emulateur est éteind.
 
la durée d'inactivité oui, j'y ai pensé mais cela n'est pas pertinent car ces sessions fantomes arrivent à consommer de la CPU (c'est bien là mon soucis).  
 
A mon avis il faudrait que j'arrive à trouver un moyen depuis HP de vérifier que les terminaux (c'est à dire l'emulateur) des utilisateurs soient encore actifs.  C'est à dire tty4, tty6....  soient vraiment présents et cela, je ne vois pas comment faire.
 
 

tu peux faire ca avec heartbeat

je vois pas comment.

t'emmerde pas et checke les drop de connection tcp sur le port idoine, ca devrait suffire.
mettre en place heartbeat n'est pas simple.
sinon pour plus de détails je te renvoie à http://www.linux-ha.org/FAQ voir "how to monitor various resources" : tu peux utiliser heartbeat2 ou mon mais c'est vraiment trop pour cela, à mon goût.
en plus t'a des users windows donc je connais pas trop bien ce qui se fait coté client, on peut imaginer plein de choses avec linux/linux mais avec windows reste-en au drop, t'aura du cpu bouffé pendant 1 à 2 minutes de trop mais de toute facon ton serveur devrait supporter la charge globale si il est bien dimensionné, donc ca ne devrait pas poser de souci.

C'est grave au fait ?

oui, l'ERP fonctionne 24/24 => au bout de 1 à 2 semaines on se retrouve avec une 50ème de connexions fantômes. 50 connexions sur le serveur ce n'est pas un soucis mais 50 connexions à l'ERP c'est 50 licenses utilisées....

un petit up pour mon pb.....

Alors ton prob est au niveau applicatif, il devrait y avoir une timeout au niveau applicatif.

oui, il y a un time-out mais qd l'utilisateur est en pleine transaction, le time-out ne marche pas. (un peu comme si tu rentrais dans un ecran de siasie et que tu commance à créer une fichier client par exmeple mais que tu ne finis pas....).
 
 
 

comportement anormal de l'utilisateur -> le rappeler à l'ordre. une transaction commencée doit être terminée, c'est jamais bon de tuer quelque chose en cours d'édition.