Projet

Général

Profil

Tâche #17822

Scénario #17595: Toujours Timeout au changement du mot de passe root (Appels au client Creole)

Essayer de reproduire le problème

Ajouté par Fabrice Barconnière il y a plus de 7 ans. Mis à jour il y a plus de 7 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Début:
17/11/2015
Echéance:
% réalisé:

100%

Temps estimé:
12.00 h
Temps passé:
Restant à faire (heures):
0.0

Révisions associées

Révision f38512c3 (diff)
Ajouté par Benjamin Bohard il y a plus de 7 ans

Déplacer la saisie des mots de passe avant l’application des paramètres du noyau.

Ref #17822

Révision 16739615 (diff)
Ajouté par Benjamin Bohard il y a plus de 7 ans

Ne pas changer la valeur par défaut du paramètre noyau net.ipv4.tcp_tw_recycle.

L’activation du recyclage des connexions ayant le statut TIME_WAIT pose problème
lorsque des connexions sont utilisées en même temps que ce changement.

Ref #17822

Révision 45dd72f7 (diff)
Ajouté par Benjamin Bohard il y a plus de 7 ans

Revert "Déplacer la saisie des mots de passe avant l’application des paramètres du noyau."

Le paramètre noyau impliqué n’est plus appliqué.

This reverts commit f38512c3b0605f739a4931d12e6e24199dac155d.
Ref #17822

Historique

#1 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Statut changé de Nouveau à En cours

#2 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • % réalisé changé de 0 à 10
  • Restant à faire (heures) changé de 12.0 à 11.0

Tentative de reproduction du problème en suivant #17498 sans succès.

--> Enfin, je ne reproduis pas le problème

#3 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • % réalisé changé de 10 à 20
  • Restant à faire (heures) changé de 11.0 à 10.0

Tentative de reproduction du problème sur Seth.
Nous avions systématiquement le problème à l'instance du serveur membre en postservice (25-manage-samba) lors du redémarrage des services pas CreoleService.
La solution temporaire a été de remplacer les CreoleService par service (eole-ad-dc:de7a95b0).
J'ai remis les CreoleService et l'instance se termine sans problème.

--> Je n'arrive pas à reproduire le problème.

#4 Mis à jour par Daniel Dehennin il y a plus de 7 ans

  • Assigné à changé de Fabrice Barconnière à Daniel Dehennin

Si j’ai bien compris, ce dont je ne suis pas sûr, le problème n’existe que durant l’instance :

  1. Une connexion à creoled est ouvert par le client creole.client.CreoleClient et reste ESTABLISHED
  2. Le paramétrage du noyau est activé par systctl (creole.reconfigure.param_kernel())
  3. Un appel à creoled par creole.client.CreoleClient renvoi un timeout

Le timeout ne se produit que si la connexion est toujours dans l’état ESTABLISHED lors du second appel.

J’ai écris un petit script python pour tenter de reproduire le problème :

#!/usr/bin/python -u

import subprocess
import re

from time import sleep

from creole.client import CreoleClient
from creole.reconfigure import param_kernel
from creole.template import CreoleTemplateEngine

established = r'127\.0\.0\.1:8000 +ESTABLISHED'
time_wait = r'127\.0\.0\.1:8000 +TIME_WAIT'
netstat = ['netstat', '-tanp']

client = CreoleClient()
engine = CreoleTemplateEngine()

engine.instance_files(filenames=['/etc/sysctl.conf'])

print "creole.client call",
for i in range(5):
    print ".",
    client.get_creole('eole_module')
print

raw_output = subprocess.check_output(netstat)
output = raw_output.decode('utf-8')

print "Param kernel" 
param_kernel()

if re.search(established, output):
    print "Connection is ESTABLISHED" 
elif re.search(time_wait, output):
    print "Connection is TIME_WAIT" 
else:
    print "Connection is neither ESTABLISHED nor TIME_WAIT" 

print "Last creole.client call: {0}".format(client.get_creole('eole_module'))

Ce qui a pour sortie, sur un 2.5.2.1 fraîchement installé et non à jour:

root@eolebase:~# ./t.py 
creole.client call . . . . .
Param kernel
-----------------------------------------------------------------------------------------------------------------------
                                           Application des paramètres Noyau                                            
-----------------------------------------------------------------------------------------------------------------------
Connection is ESTABLISHED
Last creole.client call: eolebase

#5 Mis à jour par Daniel Dehennin il y a plus de 7 ans

Chose amusante, l’exécution une seconde fois juste après la première permet de produire le problème:

root@eolebase:~# ./t.py 
creole.client call . . . . .
Param kernel
-----------------------------------------------------------------------------------------------------------------------
                                           Application des paramètres Noyau                                            
-----------------------------------------------------------------------------------------------------------------------
Connection is ESTABLISHED
Last creole.client call: eolebase
root@eolebase:~# ./t.py 
creole.client call . . . . .
Param kernel
-----------------------------------------------------------------------------------------------------------------------
                                           Application des paramètres Noyau                                            
-----------------------------------------------------------------------------------------------------------------------
Connection is ESTABLISHED
Last creole.client call: eolebase
root@eolebase:~# ./t.py 
Traceback (most recent call last):
  File "./t.py", line 17, in <module>
    engine = CreoleTemplateEngine()
  File "/usr/lib/python2.7/dist-packages/creole/template.py", line 244, in __init__
    self.load_eole_variables()
  File "/usr/lib/python2.7/dist-packages/creole/template.py", line 252, in load_eole_variables
    values = self.client.get_creole()
  File "/usr/lib/python2.7/dist-packages/creole/client.py", line 427, in get_creole
    ret = self.strip_full_path(self.get('/creole', *args, **kwargs))
  File "/usr/lib/python2.7/dist-packages/creole/client.py", line 381, in get
    ret = self.request('/get', path, **kwargs)
  File "/usr/lib/python2.7/dist-packages/creole/client.py", line 308, in request
    ret = self._request(self.url + command + path, **kwargs)
  File "/usr/lib/python2.7/dist-packages/creole/client.py", line 277, in _request
    return restkit.request(uri, method=method, backend='eventlet')
  File "/usr/lib/python2.7/dist-packages/restkit/__init__.py", line 100, in request
    headers=headers)
  File "/usr/lib/python2.7/dist-packages/restkit/client.py", line 413, in request
    return self.perform(request)
  File "/usr/lib/python2.7/dist-packages/restkit/client.py", line 353, in perform
    raise RequestTimeout(str(e))
restkit.errors.RequestTimeout: timed out

#6 Mis à jour par Daniel Dehennin il y a plus de 7 ans

  • Assigné à Daniel Dehennin supprimé
  • Restant à faire (heures) changé de 10.0 à 7.0

J’ai modifié le script pour tester en fonction de l’état de la connexion, car il semble que cela se produise juste après la fermeture de la connexion:

#!/usr/bin/python -u

import sys
import argparse
import subprocess
import re

from time import sleep

from creole.client import CreoleClient
from creole.reconfigure import param_kernel
from creole.template import CreoleTemplateEngine

parser = argparse.ArgumentParser(description=u'Test CreoleClient')
parser.add_argument('status', nargs='?', help=u"Wanted status",
                    choices=['opened', 'time_wait', 'closed'],
                    default='closed')

options = parser.parse_args()

established = r'127\.0\.0\.1:8000 +ESTABLISHED'
time_wait = r'127\.0\.0\.1:8000 +TIME_WAIT'
netstat = ['netstat', '-tanp']

client = CreoleClient()
engine = CreoleTemplateEngine()

engine.instance_files(filenames=['/etc/sysctl.conf'])

print "creole.client call",
for i in range(5):
    print ".",
    client.get_creole('eole_module')
print

print "Param kernel" 
param_kernel()

while True:

    raw_output = subprocess.check_output(netstat)
    output = raw_output.decode('utf-8')

    if re.search(established, output):
        print "Connection is ESTABLISHED" 
        if options.status == 'opened':
            break
    elif re.search(time_wait, output):
        print "Connection is TIME_WAIT" 
        if options.status == 'time_wait':
            break
    else:
        print "Connection is neither ESTABLISHED nor TIME_WAIT" 
        if options.status in ['closed', 'time_wait']:
            # Sometime there is no TIME_WAIT
            break

    sleep(0.5)

print "Last creole.client call: {0}".format(client.get_creole('eole_module'))

Je n’arrive pas à reproduire le problème une second fois après avoir restauré les paramètres sysctl:

root@eolebase:~# sysctl -a > sysctl.save
root@eolebase:~# sysctl --load=/root/sysctl.save; sleep 2; ./t.py closed
[...]
restkit.errors.RequestTimeout: timed out

C’est donc toujours :

  • La première fois que les paramètres sysctl sont appliqué
  • Après que la connexion soit fermée par le noyau (Connection is neither ESTABLISHED nor TIME_WAIT)

NB: je n’ai pas testé sur 2.6.0 avec le correctif #17408.

#7 Mis à jour par Laurent Flori il y a plus de 7 ans

Il semble que le problème vienne du paramètre

net.ipv4.tcp_tw_recycle = 1 

si on passe ce paramètre à 0 on ne reproduit plus l'erreur.

#8 Mis à jour par Benjamin Bohard il y a plus de 7 ans

  • Restant à faire (heures) changé de 7.0 à 5.0

La gestion des connexions à l’état TIME-WAIT est bien impliquée dans le problème de timeout.

Les solutions envisagées sont :
  • changement de la gestion des connexions du côté creole, restkit ;
  • changement du paramètre tcp_tw_recycle dans le template ;
  • changement de l’ordre des opérations dans l’instance pour faire passer la saisie des mots de passe avant l’application des paramètres du noyau

Aucune de ces solutions n’est facile à tester, surtout sur la 2.6.0 pour laquelle la correction déjà apportée au problème de timeout rend l’occurence de celui-ci plus aléatoire.

Sur la 2.5.2.1 avant mise à jour (pour laquelle le problème est facilement reproductible), passer la saisie des mots de passe avant l’application des paramètres du noyau résoud le problème. C’est peut-être la solution avec le moins de répercussion et la plus adaptée pour la 2.6.0.

#9 Mis à jour par Benjamin Bohard il y a plus de 7 ans

  • Assigné à mis à Benjamin Bohard
  • % réalisé changé de 20 à 100
  • Restant à faire (heures) changé de 5.0 à 0.25

Changement de l’ordre des opérations dans reconfigure.

#10 Mis à jour par Scrum Master il y a plus de 7 ans

  • Statut changé de En cours à Résolu

#11 Mis à jour par Scrum Master il y a plus de 7 ans

  • Statut changé de Résolu à En cours

#12 Mis à jour par Laurent Flori il y a plus de 7 ans

On peut reproduire le problème facilement,

lancer une eolebase-2.6.0-Daily
./mount.eole-ci-tests
cp /mnt/eole-ci-tests/configuration/aca.eolebase/default-2.6.0/etc/eole/config.eol /etc/eole/
instance (répondre non pour la mise à jour)
reconfigure ou diagnose => timeout

#13 Mis à jour par Benjamin Bohard il y a plus de 7 ans

  • Statut changé de En cours à Résolu

#14 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Restant à faire (heures) changé de 0.25 à 0.0

OK sur Eolebase 2.6.0rc4 :

root@eolebase:~# sysctl net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_recycle = 0

#15 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Statut changé de Résolu à Fermé

Formats disponibles : Atom PDF