LIDO 120 : Incidents

Cette documentation n'est utile
que pour l'administration de LIDO

Certains incidents ont été enregistrés, et sont rappelés ci-dessous, pour aider à la solution de nouveaux problèmes. Ce ne sont pas des recettes, mais principalement des pistes pour analyser une situation de défaut.

Vous trouverez peut-être d'autres incidents décrits dans /lido/general/INCIDENTS.

On ne peut pas voir ni imprimer les courbes de température.

Quand on demande la visualisation des courbes de température, rien ne se passe, et on obtient dans la fenêtre de Lancement de LIDO les messages suivants (ou à peu près) :

Fonts file not found
File graphcap is not defined
Can't get graphcap entry for nodevice
No such device nodevice
File graphcap is not defined
Can't get graphcap entry for x11
No such device x11 -title TEMPERATURES -geometry 900x800-0+0

Solution : il manque un fichier .sm dans le répertoire racine de l'utilisateur. On l'obtient comme suit :

cd ~
cp /lido/init/utilisateur/.sm    .

Essayez, cela doit ensuite fonctionner correctement.

On ne voit pas : sol console login: sur sol.

Solution (pour cette fois): un process fbconsole a pris la main dans la machine. Il faut le tuer. Cela peut être fait dans la maintenance (fonction 9)

Erreur matérielle (?) sur un disque.

A un certain moment, l'écran principal de sol s'est transformé en console, et s'est couvert de messages décrivant une erreur fatale de disque sur le disque Quantum.

Solution :

STOP-A --> le défilement des messages d'erreur s'arrête. probe-scsi ne répond pas !
On met hors tension les disques et la machine, puis sous tension.
Tout redémarre normalement, avec des erreurs mineures de disque réparées par le système au moment du boot.

Attention : dans ce cas, il faut essayer de noter le message à la main, car il n'y a pas de trace de l'incident sur le disque.

Pas d'acquisition d'images : la pose est lancée, terminée, et il n'y a pas de transmission sur le réseau.

Cela s'est produit après un reboot de sol : les gain et mode demandés étaient initialisés à 0, ce qui n'existe pas en marche normale.

En fait, la caméra est mal initialisée : suite à une erreur dans lido, on l'initialise en mode 0 ! (pas de retour chariot dans config.username, ce qui donne 0 et 0 pour le mode et le gain.)

Il n'y a pas de transmission.

Symptôme annexe : la durée d'intégration lue dans l'état de la caméra est fausse, ce qui donne des valeurs de gain incorrectes.

Solution :

1 - écrire correctement le fichier config.username, avec des retour chariot à chaque ligne !
2 - demander le filtrage systématique des paramètres d'appel des fonctions de la caméra.

La caméra reste en EFFACEMENT LENT.

Au lancement du système, la caméra reste en effacement lent longtemps (plus des 120 secondes normales).

Solution : sans sortir de LIDO, ni rebooter la caméra, il a suffi de redemander le mode de lecture (1 sortie, lecture rapide) pour que le passage en EFFACEMENT INTERRUPTIBLE se fasse normalement.

On ne peut pas se loguer sur sol.

On ne peut pas se loguer sur la console, ni par rlogin à partir d'une autre station. Le message "NIS server not responding" apparaît sur la console.

Solution (pour aujourd'hui) : on remarque que les voyants du pont filtrant et du transceiver (fibre optique --> AUI du pont filtrant) sont éteints. Par contre le hub 10baseT est actif : on voit un peu de trafic. En débranchant et rebranchant le pont filtrant (seule manoeuvre possible sur ces ponts), on remet tout dans l'ordre.

Les fichiers image ne peuvent être lus dans MIDAS.

Quand on lit un nouveau fichier dans MIDAS, par indisk (ou la procédure conv), MIDAS répond qu'il ne peut pas lire le fichier.

En fait, lors de cet incident, il ne restait plus de place sur /images. lidofits crée alors un fichier de taille nulle, et recopie ce fichier dans /bis ! On voit le volume restant dans /images et /bis dans la fenêtre d'état des poses : il était indiqué P Solution : utiliser la maintenance (fonction 6 - Détruire les données d'une nuit (volume principal)) pour faire de la place.

On ne peut pas se loguer sur la machine ... elle siffle ...

Quand on veut se loguer sur la console de la machine, on ne peut pas car elle "bipe" en permanence, et l'écran est rempli de chaines de caractères, par exemple des chiffres.

C'est simple : une touche du clavier est restée enfoncée (l'histoire ne dit pas s'il y avait un livre posé dessus !) et c'était considéré comme un login un peu long...

Les numeros de pose deviennent fous ....

on ne peut plus ecrire dans nuit.txt ....

En fait, /d1 est sature (100%), alors que normalement, il reste :

/dev/dsk/c0t1d0s5     963128  597051  269767    69%    /d1

Pour information, voici les occupations de tous les repertoires de /d1 :

sol{avin}4: du -s *
1318	Emulex
877	ES16
4	etc
2	frigo
1763	gsc
1687	gva
28646	HPXT.B05.10
8452	lido
du: lost+found: Autorisation refusée
0	lost+found
214369	midas
3040	Netscape
17147	NeWSprint
14686	NeWSprint_AB
1	opt
1260	SAOimage
43801	SUNWaadm
78533	SUNWaman
3159	SUNWaws
1	SUNWnwcin
24273	SUNWspro
12532	SUNWwabi
51240	swap
83383	tekxp
1	tftpboot
3	tmp
933	var
2103	XK
1477	xsimbad
2351	XV
sol{avin}5:

Ce qui saturait le volume, c'est le fichier

HPXT.B05.10/usr/lib/X11/xdm/xdm-errors , qui faisait de l'ordre de 280 Mo ... rempli d'ailleurs de demandes d'equinoxe du programme de precession ...

On ne pouvait donc pas ecrire dans /lido/nuit/nuit.txt, ni dans /lido/config/compteurs/poses, ce qui explique les 2 erreurs rencontrees.

Vider le fichier xdm-errors n'a pas suffi pour recuperer la place, il a fallu rebooter ... av, le 12 Janvier 1997

Alain Vin, le 16 Juin 1996