Discussion :

[free07]

Bonjour,

Ce matin, en arrivant au boulot, nous avons constaté qu'un serveur aix n'était plus joignable, il avait perdu son ip fixe et impossible de lui remettre.

On aimerait savoir ce qu'il s'est passé durant la nuit, existe t'il des fichiers traces qui pourrait nous renseigner sur le problème qui est survenue ?

Merci

[frp31]

a part fouiller /var/log.... si il y a pas de monitoring installé "avant" le crach.... y'a pas trop moyen.... sauf si tu as la chance d'avoir un core dump

avec un coredump et les outils de lecture des cores tu peux éspérer y arriver aussi...(procedure chiante mais assez efficace).

[free07]

Merci pour ta réponse

a part fouiller /var/log.... si il y a pas de monitoring installé "avant" le crach.... y'a pas trop moyen.... sauf si tu as la chance d'avoir un core dump

avec un coredump et les outils de lecture des cores tu peux éspérer y arriver aussi...(procedure chiante mais assez efficace).

J'ai fouillé dans /var/log mais rien trouvé d'interessant

Vu que je n'ai jamais utilisé de coredump, je suppose que celui-ci n'a pas été établie.
Il y a un moyen de savoir si le coredump est actif ?

[frp31]

si tu n'as pas vu de fichier cores effectivement c'est probable que ca soit pas actif.

et si tu n'as pas eu d'indices dans /var/log je crois que tu sauras jamais trop bien "pourquoi" ça a plantouillé.

pour activer le dump je sais plus trop comment on fait faudrai revoir la doc :


http://publib.boulder.ibm.com/infoce...nation/pd.html

[free07]

J'ai retrouvé les commandes suivantes :

lsattr -E -l sys0 -a fullcore qui m'affiche :

fullcore false Activation du cliché complet du fichier core Vrai

Cela voudrait dire que le coredump est actif (?)

Parceque si je fais un 'prtconf', il m'indique :

Fichier core complet : false

Je comprends pas, le 'lsattr' indique que le coredump est activé mais pas le 'prtconf'

Les fichiers cores dont tu parles sont des fichiers .cores ( extension ) ?
cela me permettra de faire une recherche de ces fichiers.

Merci pour ton aide

[frp31]

J'ai retrouvé les commandes suivantes :

lsattr -E -l sys0 -a fullcore qui m'affiche :

fullcore false Activation du cliché complet du fichier core Vrai

Cela voudrait dire que le coredump est actif (?)

à priori oui

Parceque si je fais un 'prtconf', il m'indique :

Fichier core complet : false

Je comprends pas, le 'lsattr' indique que le coredump est activé mais pas le 'prtconf'

Les fichiers cores dont tu parles sont des fichiers .cores ( extension ) ?
cela me permettra de faire une recherche de ces fichiers.

fichiers core ou cores oui selon les systèmes unix

Merci pour ton aide

il doit y avoir un conflit de configuration, tu es sencé avoir les mêmes information avec prtconf & lsattr....
bizarre...

[matafan]

Regarde toujours dans "errpt -a" si tu as un truc louche.

Finalement vous êtes arrivé à reconfigurer l'IP ?

[free07]

Finalement, il a fallu redémarrer le serveur pour qu'il reprenne son adresse ip et on avait constaté que le resolv.conf était mal renseigné, on a donc mis le bon domain et la bonne adresse ip du serveur dns vu que ceux ci avaient changé.

Par contre, nous avons eu exactement le même problème ce matin, ce serveur aix avait de nouveau une mauvais adresse ip et le pire, c'est que le resolv.conf était de nouveau avec les anciennes valeurs !!!

J'ai fait errpt -a et il indique un problème sur le bloc de batterie concernant le SCSI RAID APAPTATEUR, est que notre pb est du à cela ? à voir... je vais faire intervenir la maintenance materiel

Bon, maintenant l'adresse ip est de nouveau correct ( après re démarrage ), j'ai remis le bon nom de domaine et l'adresse ip du serveur dns dans resolv.conf

Et il y a un problème aussi avec le serveur dns vu que si je fais un dig d'une adresse ip, il répond que le serveur dns est introuvable !!!
Alors qu'un ping du serveur dns fonctionne bien.

[frp31]

pour que le resolv.conf soit réecrit il doit y avoir un probleme avec un fichier model pris en lieu et place de ce dernier...

probablement un probleme entre les données dans /etc et la base ODS ou les valeurs saisies dans smit

-----------

le problème de batterie sur la carte raid, est grave mais je ne vois pas en quoi il influrait sauf si c'est du raid mirroir et qu'effectivement le mirroir étant cassé changer les valeurs d'un coté ne les changent pas de l'autre et ducoup selon le disque qui boot... on se rertouve avec une ip ou une autre.

[free07]

J'ai vérifié les données dans smit concernant la config réseau et les infos sont identiques alors je ne sais pas ce qu'il s'est passé.
Toujours est il qu'on a du le redémarré en début d'après midi, il a bloqué au démarrage lorsqu'il cherchait le serveur dns, on l'a isolé du réseau en déconnectant le cable réseau pour qu'il démarre plus rapidement.

Lorsqu'il a démarré, on a vérifier le resolv.conf et il y avait les anciennes valeurs, je ne sais pas ou il les retrouve, toujours est il que l'on a mis les bonnes valeurs de domain et ip dns dans le resolv.conf ensuite test du dns par un nslookup et gig et pour la 1ère fois, c'était ok !! il trouve bien le serveur dns

Alors je ne sais pas ce qu'il s'est passé et c'est assez frustrant...

[frp31]

oui là moi non plus je vois plus d'autres trucs à vérifier...

[free07]

le problème de batterie sur la carte raid, est grave mais je ne vois pas en quoi il influrait sauf si c'est du raid mirroir et qu'effectivement le mirroir étant cassé changer les valeurs d'un coté ne les changent pas de l'autre et ducoup selon le disque qui boot... on se rertouve avec une ip ou une autre.

Ok, merci pour ton aide, de toute façon, je vais déclencher au + vite une intervention pour ce pb de batterie.