Projet

Général

Profil

Anomalie #4779

Blocage d'ipsec

Ajouté par Laurent HAEFFELE il y a environ 13 ans. Mis à jour il y a plus de 10 ans.

Statut:
Fermé
Priorité:
Haut
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
04/01/2013
Echéance:
15/02/2013
% réalisé:

100%

Temps passé:
0.50 h
Distribution:
EOLE 2.3

Description

Le service ipsec se bloque de temps en temps.
La commande "ipsec status" se bloque et ne retourne rien.
Cela fait basculer le service ipsec sur le sphynx secondaire (nous sommes en haute dispo).

Révisions associées

Révision f12b98f2 (diff)
Ajouté par moyooo il y a environ 12 ans

Create ticket : changing type reload form but do not check if category is always valid see #4779

Historique

#1 Mis à jour par Benjamin Bohard il y a environ 13 ans

  • Echéance mis à 01/02/2013
  • Début mis à 29/01/2013

#2 Mis à jour par Luc Bourdot il y a environ 13 ans

  • Echéance changé de 01/02/2013 à 08/02/2013
  • Début changé de 29/01/2013 à 04/01/2013

#3 Mis à jour par Laurent HAEFFELE il y a environ 13 ans

Pour information, un de nos sphynx est tombé ce matin. Je l'ai laissé en l'état (sauf quagga que j'ai été obligé d'arrêter pour rétablir le service en production).
Souhaitez-vous un accès dessus pour diagnostiquer le problème ?
Si oui, me contacter par email ().

#4 Mis à jour par Bruno Boiget il y a environ 13 ans

Envoyez plutôt un mail sur la liste eole () lorsque vous voulez nous poser une question, les remarques dans les demandes peuvent nous échapper pendant quelques jours.

#5 Mis à jour par Ludovic Landucci il y a environ 13 ans

Bonjour,

Ce matin, idem.

/var/log/zephir/agent.log :

2012/06/09 02:17:43 CEST [-] agent network : traitement ipsec
2012/06/09 02:18:43 CEST [-] agent network : traitement ipsec
2012/06/09 02:19:43 CEST [-] agent network : traitement ipsec
2012/06/09 02:20:43 CEST [-] agent network : traitement ipsec
2012/06/09 02:21:43 CEST [-] agent network : traitement ipsec
2012/06/09 02:22:43 CEST [-] agent network : traitement ipsec
2012/06/09 02:23:32 CEST [-] Received SIGTERM, shutting down.
2012/06/09 02:23:32 CEST [-] (Port 8090 Closed)
2012/06/09 02:23:32 CEST [-] Stopping factory <twisted.web.server.Site instance at 0xa015cec>
2012/06/09 02:23:32 CEST [-] Main loop terminated.
2012/06/09 02:23:32 CEST [-] Server Shut Down.
2012/06/09 02:23:43 CEST [-] Log opened.
2012/06/09 02:23:43 CEST [-] twistd 10.0.0 (/usr/bin/python 2.6.5) starting up.
2012/06/09 02:23:43 CEST [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2012/06/09 02:23:43 CEST [-] twisted.web.server.Site starting on 8090
2012/06/09 02:23:43 CEST [-] Starting factory <twisted.web.server.Site instance at 0xa883cec>
2012/06/09 02:23:45 CEST [-] debsums : pas de dernière mesure disponible.
2012/06/09 02:23:45 CEST [-] RootDebsums : pas de dernière mesure disponible.
2012/06/09 02:23:45 CEST [-] RootDebsums : pas de dernière mesure disponible.
2012/06/09 02:23:45 CEST [-] erreur mesure (debsums)
2012/06/09 02:23:45 CEST [-] Traceback (most recent call last):
2012/06/09 02:23:45 CEST [-]   File "/usr/lib/python2.6/dist-packages/zephir/monitor/agentmanager/agent.py", line 331, in scheduled_measure
2012/06/09 02:23:45 CEST [-]     m = self.measure()
2012/06/09 02:23:45 CEST [-]   File "/usr/lib/python2.6/dist-packages/zephir/monitor/agents/debsums.py", line 41, in measure
2012/06/09 02:23:45 CEST [-]     measure.append( self.get_status_from_agent(agent) )
2012/06/09 02:23:45 CEST [-]   File "/usr/lib/python2.6/dist-packages/zephir/monitor/agents/debsums.py", line 62, in get_status_from_agent
2012/06/09 02:23:45 CEST [-]     'files'     : len(agent.last_measure.value[agent.name]),
2012/06/09 02:23:45 CEST [-] AttributeError: 'NoneType' object has no attribute 'value'
2012/06/09 02:23:45 CEST [-] /!\ Agent debsums, exception during measure: 'NoneType' object has no attribute 'value'
2012/06/09 02:23:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:24:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:25:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:25:45 CEST [-] debsums : pas de dernière mesure disponible.
2012/06/09 02:26:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:27:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:27:45 CEST [-] debsums : pas de dernière mesure disponible.
2012/06/09 02:28:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:29:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:30:45 CEST [-] agent network : traitement ipsec
2012/06/09 02:31:45 CEST [-] agent network : traitement ipsec

/var/log/syslog

Feb  9 02:23:10 sphynx2.3 zephir: MAJ => FIN : 2 paquets à mettre à jour
Feb  9 02:23:13 sphynx2.3 zephir: MAJ => FIN : Mise à jour OK
Feb  9 02:23:14 sphynx2.3 zephir: RECONFIGURE => INIT : Début de reconfigure
Feb  9 02:23:27 sphynx2.3 python: PAM pam_end: NULL pam handle passed
Feb  9 02:23:39 sphynx2.3 zephir: RECONFIGURE => FIN : reconfigure terminée
Feb  9 02:30:05 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage
Feb  9 02:40:04 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage
Feb  9 02:50:04 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage
Feb  9 03:00:04 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage
Feb  9 03:10:04 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage
Feb  9 03:20:05 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage
Feb  9 03:30:05 sphynx2.3 zephir: ZEPHIR => MSG : Service z_stats arreté : redémarrage

#6 Mis à jour par Joël Cuissinat il y a environ 13 ans

  • Echéance changé de 08/02/2013 à 15/02/2013

#7 Mis à jour par Fabrice Barconnière il y a environ 13 ans

J'ai eu accès à un Sphynx dans cette situation. L'agent Zéphir avait lancé plusieurs "ipsec listcerts" et "ipsec statusall".
Après plusieurs arrêts de z_stats puis plusieurs "killall stroke", et un kill de "/usr/lib/ipsec/charon --use-syslog" qui n'avait pas de process père "/usr/lib/ipsec/starter", z_stats s'est relancé et ipsec s'est débloqué sans le relancer.
D'où sort ce process charon sans process père ?

#8 Mis à jour par Laurent HAEFFELE il y a environ 13 ans

D'où sort ce process charon sans process père ?

C'est probablement le processus charon classique qui a été reparenté sur le processus 1 à cause d'un plantage du processus starter.

#9 Mis à jour par Fabrice Barconnière il y a plus de 10 ans

Sur EOLE 2.4 on peut indiquer un timeout du processus stroke (3000ms par exemple).
On peut également indiquer à l'agent de ne rien tenter pendant la mesure (ipsec up/down "connexion"), ce qui ne semblait pas arranger les choses: Agent Zéphir RVP en mode 'No action' à 'oui'.
Une proposition de scénario (#12068) est déjà présente pour supprimer ce mode dans l'agent Zéphir.

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

  • Statut changé de Nouveau à Fermé
  • % réalisé changé de 0 à 100

Formats disponibles : Atom PDF