Demande #19768
Un seul attribut calculé peut-il faire planter eole-sso ?
Description
Description du pb :
- un script local de calcul d'attributs (placé dans /usr/share/sso/user_infos) se connecte à une base de données distante pour faire un select
- hier le serveur BDD auquel il se connecte tombe en rideau pour une raison externe
- le script (ceci est une supposition) reste indéfiniment en attente de réponse
- Résultat : l'ensemble du service eole-sso ne répond plus
- nous avons testé eole-sso (juste après un redémarrage) avec une application qui n'utilise pas cet attribut: or cela plante également
- après renommage du script, le service eole-sso répond à nouveau
Questions :
- est-il normal que l'ensemble du service eole-sso plante si un attribut calculé ne fonctionne pas ?
- est-il normal aussi qu'un attribut soit calculé y compris s'il n'est pas requis par l'application appelante ?
Dans les deux cas :
- si la réponse est oui, peut-on envisager une évolution ? (Par exemple pour le premier cas, prévoir un timeout pour le calcul des attributs, ou bien "flagger" un attribut comme unresponsive et empêcher son exécution pendant un certain temps ?)
- si la réponse est non, avons nous loupé quelque chose dans notre configuration ?
- Enfin, y a-t-il une possibilité que les scripts d'attributs calculés en cours d'exécution soient logués ou visibles quelque part ?
En effet nous n'avons rien trouvé dans les logs ou les processus en cours nous permettant de nous mettre sur la voie
J'ai présenté au départ le problème de manière inversée, mais durant plusieurs heures le eole-sso académique (qui permet l'accès à l'intranet et donc à toutes les applications ARENA pour tous les personnels, et notamment à IPROF en période de mouvement) ne répondait plus, nous avons mis plusieurs heures avant d'avoir l'intuition que ce script puisse être à l'origine du problème...
Historique
#1 Mis à jour par Bruno Boiget il y a environ 9 ans
- Statut changé de Nouveau à En attente d'informations
- Assigné à mis à Bruno Boiget
Quelques éléments de réponse :
- L'ensemble des attributs est calculé indépendamment de l'application appelante, et filtrés ensuite.
- Pour limiter les problèmes de charge, l'ajout de "use_cache=True" dans un fichier d'attribut fait que l'attribut est stocké en mémoire pour la durée de la session (au lieu de recalculé à chaque fois).
- Le service EoleSSO utilise une librairie qui n'est pas multithreadée. Si un calcul d'attribut reste bloqué, l'ensemble du service peut effectivement se retrouvrer en attente.
Pour limiter des blocages trop longs, le timeout par défaut des connexions est fixé à 5 secondes (SOCK_TIMEOUT = 5.0 dans le fichier /usr/share/sso/config.py).
J'ai fait un test en ajoutant un appel sur un port bloqué par un pare-feu dans un des attributs calculés, celui-ci s'est bien débloqué après 5 secondes avec le log suivant :
2017-03-17T17:09:39.026597+01:00 scribe.etb1.lan eole-sso[2658]: 2017-03-17 17:09:39+0100 [-] ! Erreur lors du calcul des données de l'attribut 'secureid' : timed out
Suivant la librairie utilisé pour l'accès à la base de données, il est possible que ce timeout ne soit pas pris en compte.
Pouvez vous nous fournir plus d'information (si possible, le fichier ajouté) pour essayer de reproduire le problème ?
#2 Mis à jour par Renaud Dussol il y a environ 9 ans
Merci de votre réponse qui déjà nous éclaire déjà beaucoup :
- je pense que le use_cache ne nous aurait pas aidé dans notre cas précis, car le pb se produisait dès la première connexion. En revanche nous allons l'utiliser car ce paramètre est certainement très intéressant pour les scripts gourmands. Cela va sans-doute accélérer l'accès à certaines applications
- Effectivement la librairie utilisée n'est peut-être pas standard, car il s'agit d'une base firebird et donc d'une librairie client firebird (fdb). Je vous copie le script en question ci-dessous.
Ce script n'étant pas très important , car utilisé pour un service secondaire en voie de disparition, nous l'avons supprimé.
J'avais surtout peur car nous utilisons un autre script, basé sur la librairie mysql, qui lui est central dans notre système.
si le système de timeout fonctionne avec la librairie mysql, cela me rassure.
Je ferai un test en coupant le lien réseau avec le serveur mysql appelé par ce script pour voir si le timeout fonctionne
Merci encore
----------------------------------------------Le script en question :
----------------------------------------------
coding: utf-8
import fdb
def calc_info(user_info):
con = fdb.connect (dsn='chronos.in.ac-nice.fr/49100:D:\Bodet\open\database\open_db.fdb',user='**********', password='***********')
- Create a Cursor object that operates in the context of Connection con:
cur = con.cursor()
- Execute the SELECT statement:
cur.execute("SELECT UTILISATEUR_ FROM UTILISATEUR WHERE LOGIN_ = '%s'" % (user_info['uid'][0]))
- Retrieve all rows as a sequence and print that sequence:
iduser = cur.fetchall()
try :
return (iduser0)
except :
return ([])
#3 Mis à jour par Gérald Schwartzmann il y a presque 9 ans
- Assigné à changé de Bruno Boiget à Gérald Schwartzmann
Bonjour,
Est-ce que la demande a toujours lui d'être ? sinon on procède à sa fermeture
Est-ce qu'une solution a été trouvée ? si oui merci d'ajouter un complément d'information.
Cordialement
#4 Mis à jour par Gérald Schwartzmann il y a plus de 8 ans
Bonjour,
Est-ce que la demande a toujours lui d'être ? sinon on procède à sa fermeture
Est-ce qu'une solution a été trouvée ? si oui merci d'ajouter un complément d'information.
Cordialement
#5 Mis à jour par Renaud Dussol il y a plus de 8 ans
- Fichier listes_sympa.py Voir ajouté
Bonjour et désolé, je n'avais pas vu la première relance
Il est vrai que le script "problématique" ne menace plus, nous l'avons supprimé, donc je ne pensais plus à ce problème
En revanche suite à la relance, j'ai fait le test que j'indiquais (avec un autre script que nous utilisons toujours et qui est indispensable, nous ne pouvons donc pas l'enlever)
J'ai coupé la liaison réseau avec le serveur mysql appelé par ce script, et le timeout ne fonctionne pas
Le comportement est cependant meilleur qu'avec le script précédent car le serveur reprend la main au bout de 2 minutes avec l'erreur :
2017-08-30T14:50:51.744190+02:00 eolesso-ihd.in.ac-nice.fr eolesso: [HTTPPageGetter (TLSMemoryBIOProtocol),client] ! Erreur lors du calcul des données de l'attribut 'listes_sympa' : (2003, "Can't connect to MySQL server on 'sympav6.ac-nice.fr' (110)")
Mais il s'agit du timeout du serveur mysql, qui libère la connexion (et qui doit être à 120 secondes), et non du timeout de 5 secondes du eolesso
J'ai vérifié dans le fichier /usr/share/sso/config.pyconfig.py, et j'ai bien SOCK_TIMEOUT = 5.0
Au bout de 2 minutes, l'utilisateur est bien authentifié, mais c'est quand même très long et difficilement acceptable en production
Il s'agit peut être d'un mauvais paramétrage de mon script (ou de l'utilisation d'une librairie client mysql non compatible ? J'utilise MySQLdb)
Je vous joins le script incriminé pour vérification
Merci et encore désolé d'avoir laissé trainer
#6 Mis à jour par Gilles Grandgérard il y a environ 8 ans
des pistes d'optimisation :
- ajouter un timeout à la connexion au lieu d'utiliser la valeur par défault
MySQLdb.connect(host=self.h, user=self.u, passwd=self.p, db=self.d, connection_timeout=1)
- elle peut être definie dans my.cnf
- le processus est récursif ==> pourquoi ouvrir et fermer autant de connexion que de requête ? connectionObject_sympa/c_sympa pourraient être dans init et utilisées globalement
#7 Mis à jour par Renaud Dussol il y a environ 8 ans
Merci pour les pistes, je vais essayer le timeout dans le script sur un eolesso de test. Je n'ai pas la main sur le serveur mysql sympa, mais je peux en parler à l'équipe système
Pour la connexion ouverte à chaque requête, il me semble qu'au tout début, j'avais mis la connexion dans le init en utilisant une seule connexion pour toutes les requêtes mais que cela posait problème... Cela fait longtemps je vais essayer de retrouver, mais il me semble de mémoire qu'au bout d'un certain nombre de requêtes, la connexion était perdue et que les requêtes retournaient une erreur, ce qui m'avait obligé à procéder de la sorte en ouvrant une connexion à chaque requête
#8 Mis à jour par Joël Cuissinat il y a plus de 6 ans
- Statut changé de En attente d'informations à Classée sans suite