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:
Services manquants | Raison ou informations | Solution ou piste |
|
les services python n'ont pas démarrés sur glslogin1 | sous superUser@glslogin1 vérifier l'absence des processus et lancer:
/opt/t4/beta/scripts/services_python& |
|
requête OPC/UA sur PLC ETCS pour cimier/volet et requêtes modus sur PLC-flap pour flap | |
|
requête OPC/UA sur PLC ETCS | PLC-ETCS |
|
requête modus sur 10.10.132.23 | Capteur Comet |
|
requêtes modus sur 10.10.132.100 (admin+...) | UPS local L-105 |
|
le bus de terrain serie Adam a un soucis |
|
|
Adam + ... + sonde local Coralie |
investigation glsserv |
|
Adam 0-10V+ convertisseur PT100-0-10V local Coralie |
investigation glsserv |
|
Adam 0-10V+ convertisseur PT100-0-10V local Coralie |
investigation glsserv |
|
Adam 0-10V+ convertisseur PT100-0-10V local Coralie |
investigation glsserv |
|
Adam + ... + sonde local Coralie | investigation glsserv |
|
Adam 0-10V+ convertisseur PT100-0-10V intérieur embase t120 | investigation glsserv |
|
Adam 0-10V+ convertisseur PT100-0-10V intérieur embase t120 | investigation glsserv |
|
script service_meteoColumbia ou station meteo | investigation sur 10.10.132.24 |
|
lakeshore serie local Coralie, Moxa Serie chassis LCU | investigation glsserv |
|
probleme PLC-clim2 | investigation et reboot PLC-clim2 |
|
panne courante | tuer les processus associé sur glsserv, relancer selon code dans /opt/t4/beta/scripts/services |
|
Jumo sur chassis tournant Necam | |
soit:
|
ce sont des bornes Adam 6015 (internet), donc problème lié à une borne | investiguer (ping) |
|
lakeshore FP | investiguer sur glspc17, ligne USB |
|
sonde Pfeiffer | investiguer sur glspc17, ligne série |
|
Jumo sur chassis Necam et module Moxa serie | investiguer sur le contrôleur, son alimentation, la connection serie avec glsecam |
|
Moxa Serie chassis LCU | investiguer sur le controlleur dans le local Coralie. |
|
concerne un ensemble de controller
|
Invertigation dans les fichiers de log: $TDATA/services/MAINTENANCE/necam:
|
|
Liés au soft d'observation, valeur de position de M2 | investiguer dans les procédures |
|
Liés au soft d'observation, valeurs lue sur le site du meteo monitor |
souvent en panne, investiguer dans les procédures |
soit:
|
Données de réduction Coralie, Probléme software liés à l'analyse des Fits de la nuit | investigation software |
soit
|
décommissioné, état normal, données gardées comme historique | -- |
|
décommissioné, état normal, données gardées comme historique | -- |