Tâche #35509
Scénario #35468: file d'attente bloquée (problème UUCP ou SSH)
Étude
0%
Historique
#1 Mis à jour par Laurent Gourvenec il y a 10 mois
- Statut changé de Nouveau à En cours
En ce qui concerne l'erreur "service : commande introuvable"¶
A priori, c'est parce que le script est exécuté avec le user uucp, ou une erreur du genre.
-> A corriger, mais sans doute rien à voir avec le soucis global
A propos du socket.timeout¶
Des logs coté zéphir nous aiderait à déterminer le problème. Peut-être lié aux erreur 'uucp@DOMAINE: Unroutable address' ; c'est comme si un problème réseau survenait au moment de l'import...
À propos du lock global¶
Hypothèse à vérifier : une erreur réseau empêchant z_stats de remonter les infos au zéphir créé le lock
-> Le problème de lock permanent a été adressé. Voir https://dev-eole.ac-dijon.fr/issues/34909
#2 Mis à jour par Benjamin Bohard il y a 8 mois
Concernant le premier fragment de log transmis dans la demande, il semble bien y avoir deux problèmes indépendant :
- la commande tar créant l’archive siteXXX.tar est en échec
- exim ne peut pas envoyer de courriel à uucp@DOMAINE parce qu’il n’a pas de règle déterminant où l’envoyer (unroutable address).
Pour le premier problème, les erreurs de ce type était rencontrées alors qu’une archive précédente était encore présente dans le réperoire. Ce problème semble par ailleurs être résolu.
Dans le second problème, il faudrait vérifier que @DOMAINE (je suppose que cette partie du log est anonymisée) existe bien.
#3 Mis à jour par mathieu carrolle il y a 8 mois
Benjamin Bohard a écrit :
Concernant le premier fragment de log transmis dans la demande, il semble bien y avoir deux problèmes indépendant :
- la commande tar créant l’archive siteXXX.tar est en échec
- exim ne peut pas envoyer de courriel à uucp@DOMAINE parce qu’il n’a pas de règle déterminant où l’envoyer (unroutable address).Pour le premier problème, les erreurs de ce type était rencontrées alors qu’une archive précédente était encore présente dans le réperoire. Ce problème semble par ailleurs être résolu.
Dans le second problème, il faudrait vérifier que @DOMAINE (je suppose que cette partie du log est anonymisée) existe bien.
Bonjour,
Pour le problème d'envoi d'email, la valeur de @DOMAINE est anonymisée. Elle correspond au nom de domaine Active Directory de l'établissement (service fournit par le module scribe): e.g monetab.local
#4 Mis à jour par Benjamin Bohard il y a 5 mois
Pour l’instant, je n’ai réussi à reproduire l’erreur de persistance du fichier siteX.tar qu’en injectant un bug dans les actions du client zéphir (dans zephir_client.py). Pour ne pas avoir le problème de blocage, on peut s’assurer que l’ancien fichier siteX.tar ne soit plus présent avant la tentative de création de la nouvelle archive. Par contre, ça n’explique en rien pourquoi cette archive n’est pas supprimée en premier lieu.
Par ailleurs, aucun problème de lock n’a pu être reproduit pour l’instant. Les logs consultés ne mentionnant que le problème de persistance du fichier siteX.tar, le rôle du lock est inexpliqué.
#5 Mis à jour par mathieu carrolle il y a 2 mois
Bonjour,
Les erreurs concernant l'envoi d'email et la présence du fichier archive (e.g./tmp/site16.tar) ne sont plus présente.
Par contre, il y a toujours un problème de lock avec zephiragents.
J'observe que régulièrement la synchro n'est plus opérationnelle entre le scribe et le serveur zephir.
Logs du serveur scribe ( journalctl -u z_stats ) :
févr. 26 13:31:29 serveur01 zephiragents[2526]: 2024-02-26T13:31:29+0100 [-] Deleting stalled archive file févr. 26 13:31:29 serveur01 zephiragents[2526]: [-] Deleting stalled archive file févr. 26 13:36:29 serveur01 zephiragents[2526]: 2024-02-26T13:36:29+0100 [-] Deleting stalled archive file févr. 26 13:36:29 serveur01 zephiragents[2526]: [-] Deleting stalled archive file
Sortie console de la commande synchro_zephir :
Erreur : un fichier de bloquage est présent. Des actions sont déjà en cours ou un action précédente ne s'est pas terminée correctement. Contactez l'administrateur Zéphir ou débloquez les actions avec la commande : - /usr/share/zephir/scripts/zephir_client del_lock
En vérifiant on observe que le fichier lock /var/lock/reconfigure est effectivement présent.
Pour débloquer, j'exécute la commande suivante: /usr/share/zephir/scripts/zephir_client del_lock
#6 Mis à jour par Laurent Gourvenec il y a environ 2 mois
Bonjour,
contrairement à ce qu'on pourrait penser, le fichier de lock /var/lock/reconfigure ne signale pas qu'un reconfigure est en cours d'exécution (autrement, le fichier serait dans /var/lock/eole/eole-system/). Cependant, quand ce fichier est présent, il est normal que la synchronisation zéphir échoue. Il semble donc que ce fichier soit créé mais que le programme qui l'a créé ne l'ait jamais détruit.
Je vois un endroit dans le code où on cré ce lock et où le script pourrait mal se terminer : service_restart.py, les signaux ne semblent pas gérés. Cependant, cela veut dire que le script est appelé via zéphir (action "redémarrer un service").
2 solutions possibles :
- merger les lock eole et les lock zéphir (extrêmement risqué)
- gérer les signaux/BaseException dans le script service_restart.py
Mathieu,
- est-ce que le fichier reconfigure est le seul fichier de lock présent dans /var/lock ?
- est-ce que tu utilises la fonction "redémarrer un service" dans zéphir ?