Procédure en cas d'arrêt du monitoring des services

 Ce mémo traite des différentes solutions permettant de réagir à différents cas d'arrêts des services:

Attention il vous faudra de supers pouvoirs (root en autres) !

Arrêt d'un seul service

Il est possible que le fichier soit corrompu suite à des problèmes d'écriture, NFS ou autres. Si le problème n'est pas solutionné en suivant la procédure suivante, il faut passer au dernier chapitre ("Un ou plusieurs services arrêtés"). 

Procédure:

# connexion x2go sur glslogin1 
sudo -s
cd $TDATA/services/<service>/

Le fichier courant s'obtient avec la commande:

ls -rtl

D'abord vérifier si le fichier est à jour:

1) determiner le temps unix actuel avec:

date +%s

puis regarder le temps unix écrit sur la dernière ligne du fichier avec:

tail -1 < <last_fichier>

Si les deux temps sont cohérents, cels signifie que le service fonctionne.

Sinon il faut le relancer le service (voir glsserv:$THOME/scripts/services et glslogin1:$THOME/scripts/services_python) voir également ce document pour plus d'info (si besoin).

Si le fichier est à jour, alors c'est qu'il est peut-être corrompu (erreur d'écriture).

On vérifie si le fichier courant n'est pas corrompu avec la commande:

check < <last_fichier>

exemple

cd $TDATA/services/c2_temp
check < c2_temp_202108.rdb

S'il y a un message d'erreur, il faut corriger le problème.

Attention, il s'agit d'une simple edition, mais comme le service se met à jour selon certains intervals de temps (10[s]..10[minutes]), l'edition et le sauvetage du fichier doit impérativement se faire durant cet interval.

Personnellement j'utilise nedit (sous root sous glslogin1) et je clique dans le fichier de temps en temps jusqu'à que nedit me propose de recharger le fichier car il a été modifié. A ce moment, je le recharge, je fais la modification et je le sauve avant la fin du temps imparti.

Si c'est le service Necam ou Ups, il est préférable d'arrêter le service si on n'est pas sur de réussir l'édition en 10[s]

Si le problème signalé indique que le fichier n'a pas de header, alors il faut éditer le fichier d'un mois précédent (avec un header correct) et faire un copy-paste des 2 premieres lignes dans le fichier corrompu.

Normallement, cette action règle le probleme.

Tout les services sont arrêtés

Ce cas est détecté sur le rapport journalier ou sur l'écran de monitoring qui indique que les données sont trop anciennes.

On commence par une rapide verification pour déterminer l'origine de la panne.

Remarque: Le rapport journalier utilise la BDD PostgresSql de Genève (sur 10.194.64.12 mis à jour par trmgr@obstr01) et l'écran de monitoring utilise la BDD PostgresSql de La Silla (sur glsmonitor). Si les fichiers rdb de La Silla sont à jour, c'est que les services fonctionnent mais que la mise à jour d'une ou des 2 BDD ne fonctionne pas.

Vérification rapide sur glslogin1.ls.eso.org:

cd $TDATA/services/
ls -l */*<YYYYMM>*.rdb

On donne la date du mois courant, exemple: 202108 pour le mois d'aout 2021.

Le résultat devrait donner une date récente (<10[minutes]) pour l'ensemble des fichiers, à l'exception des services temperature_telescope, focus, seeing qui ne se remplissent que durant l'observation. Ceci devrait être le cas sinon nous avons affaire à un problème plus profond.

Apres cette veerification, on peut être certain que c'est un problème de transmission qui est à la source de la défaillance du monitoring.

Les opérations suivantes demandent certains privilèges: super-user sur glsmonitor et trmgr sur obstr. Pour un login sous trmgr sur obstr01, seul Nicolas Buschchacher et Luc Weber peuvent vous aider..... 

A) Opérations sur la BDD de Genève

On liste les process:

ssh login01.astro.unige.ch
ssh trmgr@obstr01
ps -ef | grep -i meulup

En temps "normaux" on devrait avoir zéro ou une ligne montrant un process avec Meulup.jar (update de la BDD en java). Sinon et surtout si on en voit des dizaines, c'est que Meulup, ou la synchronisation depuis LaSilla ont un problème.

Le fichier /home/trmgr/MONEULER/Meulup.log renseigne sur les problèmes survenus durant la dernière synchronisation. Normalement ce devrait du à un problème de dépassement mémoire (il est clair que cet état demande une étude du code pour éviter ce genre de comportement ...)

La solution est de tuer ces processus de la manière suivante:

pkill -f Meulup.jar
ps -ef | grep -i meulup

 Cette technique peut malgré tout laisser trainer des processus, dans ce cas il faut les tuer selon leur PID avec:

kill -9 <pid1> [<pid2 [...]]

 Un ultime 

ps -ef

renseigne sur l'état des processus en cours et une autre cause possible du problème. Attention certains processus de synchronisation des données raw peuvent être présents. Ainsi, il est nécessaire d'agir avec prudence.

Comme la mise à jour sur Genève se fait toutes les 10 minutes (voir crontab -l) , il faut patienter pour voir les effets avec meulplot par exemple.

B) Opérations sur la BDD de La Silla

Les opérations de récupération dans la BDD locale sont identiques à ceux de Genève (tuer les processus bloqués), à l'exception que l'on ne voit pas apparaitre de synchronisation car il n'y en a pas. Seul le processus Meulup.jar est le responsable. Le fichier de log de Meulup est /home/weber/Meulup.log.

Un ou plusieurs services sont arrêtés

Ce cas est détecté sur le rapport journalier ou sur l'écran de monitoring qui indique que les données sont trop anciennes.

Si une partie des services est à jour cela signifie que la synchronisation fonctionne mais:

• soit certains services ne tournent pas
• soit le processus de mise à jour de la base de donnée (Meulup.jar) plante sur un service, empêchant la mise à jour des services suivants (sur la liste de mise à jour) d'être ajouté à la BDD. Dans ce cas, le fichier de log de Meulup donnera des infos et soit il faut se reporter au premier cas, soit c'est un problème software de l'application java Meulup.

Dans le cas de service qui ne tournent pas:

Il faut se rappeler que certains services sont liées entre eux soit par la nature de leur fonctionnement (bus terrain, requête série, requête OPC/UA, etc) ou soit par ordinateur sur lequel ces services tournent (glsserv ou glslogin1). Ainsi seul un minimum de connaissance du fonctionnement de services peut aider à solutionner le probleme.

Pour info on peut lister certains cas et actions:

En general tous les services ont un point de départ sous $THOME/scripts/service_<service>, c'es tune bon point de départ pour les investigation software.

Le document donne également beaucoup d'information, notamment que plusieurs services peuvent effectuer une requête unique pour test (voir option -H et -U)

Quelques infos: