Distribution EOLE » Modules » Zéphir

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.

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

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é.

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

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 ?

Bonjour laurent,

Non, je n'utilise pas spécifiquement la fonction "rédémarrer un service" du zephir. Au niveau du zephir, nous utilisons principalement que la synchro des comptes aaf chaque nuit.

Voici le contenu du dossier /var/lock:

root@serveur01:~# ls -R /var/lock/
/var/lock/:
apache2  bastion  configure  controle-vnc  eole  lvm  ntpdate  reconfigure  subsys  uucp

/var/lock/apache2:

/var/lock/eole:
eole-system

/var/lock/eole/eole-system:

/var/lock/lvm:

/var/lock/subsys:

Navré pour le délai de réponse, je suis passé à coté de la demande.

Bonne journée

Je vois 2 problèmes restants :
1. La connexion au zéphir qui termine en timeout
2. Les fichiers de lock (configure reconfigure uucp et maj) qui restes après un échec du script, ce qui bloque toutes les prochaines synchro.

Pour le premier problème, il nous faudrait les logs coté zéphir (services ssh et zephir du serveur zephir) au moment de l'incident. Surcharge du serveur ? Traitement pour un autre serveur trop long ? Un ajout de retry est en cours de développement.
Pour le second problème, un développement est en cours.