Manuel de maintenance pour l'observation

Window manager planté

Cele peut arriver au démmarrage des applications. Dans ce cas:

Tuez tout les process selon la FAQ:comment_tuer_tous_les_process depuis une autre machine.

Puis tuez le window manager (de la machine plantée) selon:

ps -ef | grep Xsession
kill -9 <no de processes>

Processes bloque

Si on ne peut démmarrer l'ensemble des applications du à un blocage de l'utilitaire "processes". (Le premier à être lancé)

Il faut:

  1. le tuer (ps -ef | grep processes ,... )
  2. rm ~/.processes*

Attention il peut être bloqué car un des PC est hors circuit! Donc vérifiez cela avant.

LW/23/10/98

Comment tuer tous les process

Si pour une raison quelconque vous avez besoin de tuer tout les process (liés à l'observation bien sûr) et que "processes" est innaccessible (machine plantée, window manager planté, "processes" mort ou planté, ...)

Si votre machine est bloquée mettez vous sur une autre machine et loggez vous sur la machine défaillante. Sinon restez sur votre machine.

1er cas: votre machine est toujours accessible:

tuez "processes", lancez "processes" et effectuez un "KILL local+remote". C'est à dire:

        ps -ef | grep processes
        kill -9 <No_du_process>
        processes
                => click sur "KILL local+remote"

2eme cas: votre machine innaccessible:


Loggez vous sur une autre machine, mettez le bon display, tuez "processes", lancez "processes" et effectuez un "KILL local+remote". C'est à dire (exemple: ouranos planté et action depuis cronos):

        <login sur cronos>
        rlogin ouranos
        setenv DISPLAY cronos:0.0
        ps -ef | grep processes
        kill -9 <No_du_process>
        processes
                => click sur "KILL local+remote"

LW/15/10/1998

Les poses ne s'arrêtent pas

Description du phénomène:

Une fois la pose lancée, par exemple une pose de calibration de 60 secondes, le tracé du taux de comptage sur l'UIF affiche la présence du flux, puis, au bout des 60 secondes, le flux retombe à zero, donc le shutter se ferme, mais le contrôle n'est pas rendu sur l'UIF.

Il y a une indice supplémentaire, le champ "courant" du panneau "Temps d'exposition" reste sur "0".

Résolution du problème

Cela peut indiquer deux choses:

Pour tester la déconnection entre le spectro_srv et l'UIF, on tape sur le prompter Coralie:

        shut /arm
        shut /open

Si sur le panneau xsdbmanager de coralie le champ "temps d'exposition" s'incrémente. C'est qu'il y a effectivement une déconnection entre spectro_srv et UIF. Dans cette situation, il faut simplement descendre le spectro_srv. On tape sur le prompter Coralie:

        spe /quit
        quit

On sort ainsi du spectro_srv et de Coralie. Dans xrunall on relance Coralie. Quand son initialisation est terminée tout doit fonctionner normallement.

Par contre si sur le panneau xsdbmanager de coralie le champ "temps d'exposition" ne s'incrémente pas. C'est un problème pas encore géré, et il faut dans ce cas descendre Coralie et spectro_srv (comme indiqué plus haut) et rebooter glspc1 (CTL-ALT-DEL). Une fois le PC reparti, il faut relancer Coralie sur xrunall et c'est normallement OK.

LW/20/10/1998

Marche à suivre pour debugger le Synchro en mode d'opération

Traitement_des_erreurs sous Inter, principe general

Chaque message d'erreur généré par Inter ou un de ses clone est est fabriqué à l'aide d'un format contenu dans un fichier de type dbm (<nom>.dir et <nom>.pag) situé dans le repertoire $INTERHOME.

Ces formats sont accédés par une clé. Par exemple la clé

'int_noqual'

est associée au format

'Ce qualificateur est inconnu : "%s"'.

Lorsque Inter désire afficher cette erreur, il le fait de la manière suivante:

call int_errare('int_noqual', qualif(1:ilen)//char(0))

Avec cet appel, une erreur interne est générée (flag), le message est imprimé à l'ecran, envoyé sur le logbook si on est connecté et inscrit (avec la clé) dans le bloc de communication de mémoire partagée en mode serveur.

Un Inter-client qui a lancé une commande sur un Inter-serveur récupère (en cas d'erreur) le message d'erreur formatté ainsi que la clé. Cette dernière peut lui permettre de modifier le derroulement des opérations.

Fabrication du fichier dbm

Le fichier dbm est fabriqué automatiquement lors de chaque compilation d'un Inter avec la commande 'create_dbmerr'. Il lit des fichiers ASCII contenant sur chaque ligne la paire <clé> <format> séparés par un ou plusieurs tabulateurs.

'create_dbmerr' concatène les fichiers donnés sur la ligne de commande données dans le Makefile. Par exemple, pour ccd, le Makefile contient:

create_dbmerr inter.err.fr ccd.err.fr

'create_dbmerr' tue puis crée les fichiers 'dbmerr.pag' et 'dbmerr.dir'

Choix de la langue

Il serait possible d'afficher les messages dans une autre langue si les fichiers type '*.err.fr' étaient traduit (mais cela n'est pas le cas). L'extension '.fr' signifie d'aileurs "français".

Genéralisation aux procédures

Pour permettre de gérer les erreurs générées dans les procédures, les procédures doivent inclure le code suivant, équivalent au code Fortran ci-dessus:

erreur /code="int_noqual" qualif

Le choix des codes d'erreur pour les Inter sont figés. Comme ce n'est pas le cas pour les procédures (developpement plus actif), les couples <clé> <format> sont lus au lancement d'un Inter dans un ou plusieurs fichier ASCII et ajoutés à la base dbm. C'est l'option:

'-code <path>:<extension>' qui déclenche ce mode de fonctionnement.

Remarque: Comme dans ce cas la base doit être ouverte en R/W et que la base originale est protégée en écriture, Inter fait une copie de la base sous '$HOME/.inter_dbmerr_<pid>.pag' et '$HOME/.inter_dbmerr_<pid>.dir'. Cette base est tuée en fin normale de travail.

L'option '-code <path>:<extension>' signifie: concatène tous les fichier avec extension <extension> dans le directory <path> dans la base de code d'erreur courante. Ex:

synchro -server -code $T4HOME/config/errcode:.fr

Regles

Tout message qui sort d'une procédure devrait être écrit selon son code. Cela permet le changement de langue et le traitement des erreurs en amont. Les deux commandes à disposition sont:

        write  /code=<code> [<arg> ...]
        erreur /code=<code> [<arg> ...]

Chaque développeur de procédure peut maintenir un ou plusieurs fichier de message d'erreur (comme il maintient des procédures). Ces fichiers doivent être placés sous "$T4HOME/config/errcode" et avoir l'extension ".fr". L'usage de préfixe ou d'extension permettant de différencier les divers emplois de ses messages sont les bienvenus, par exemple:

        spe_config.fr
        ccd_pointage.fr

De plus les codes eux-mêmes doivent être précédé d'un préfixe afin d'eviter les synonymes.

Les préfixes "int_", "ccd_", "t12_", "spe_", "tac_" sont déjà utilisés par les Inters: "inter", "ccd", "t120", "spectro" et "tacos".

Attention, en cas de synonyme, c'est le dernier message lu qui fait référence. C'est donc une situation à éviter absolument.

Comme la gestion des erreurs au niveau du Synchro est basé sur le code d'erreur, l'emploi d'un code d'erreur ne doit pas être modifié. Le message, lui, peut naturellement être modifié.