NON URGENTE TEMPORAIRE DEFINITIVE

COMMUNICATION TECHNIQUE N TC0296 Ed. 02 OmniPCX 4400/Enterprise Nb de pages : 11 Date : 26-11-2003 URGENTE NON URGENTE TEMPORAIRE DEFINITIVE OBJET : RELEVÉ D'INFORMATIONS EN CAS DE Cette communication technique fournit des trucs et astuces concernant des problèmes CPU tels que redémarrage, arrêt de l'application téléphone ou impossibilité de se connecter au système. 1

RELEVÉ D'INFORMATIONS EN CAS DE OmniPCX 4400/Enterprise SOMMAIRE 1. INTRODUCTION...3 2. TRUCS ET ASTUCES SUR LES...3 2.1. Qui a initialisé le redémarrage du système?... 3 2.1.1. Redémarrage automatique...3 2.2. Le téléphone s'arrête... 4 2.3. Une CPU redémarre continuellement... 4 2.3.1. Problème avec la configuration IO2...4 2.3.2. Problème avec la carte IO2...4 2.3.3. Reboot CPU lié à l'io2...4 2.3.4. Problème avec des fichiers OPS...5 2.4. Corruption de la base de données... 5 2.5. Contrôle de l'installation de la version logicielle... 6 2.6. Contrôle des ports V24... 6 2.7. Capture d'informations systèmes... 6 3. INVESTIGATIONS MATÉRIELLES...7 4. INFORMATIONS À RELEVER POUR OUVRIR UNE DEMANDE DE SERVICE...7 4.1. Description du problème... 7 4.2. Description des investigations... 7 4.3. Fichiers log des incidents... 8 4.4. Fichiers log des exceptions téléphone... 8 4.5. Fichiers log des black boxes... 8 4.6. Fichiers log du téléphone... 8 4.7. Fichiers log de Chorus... 9 4.8. Fichiers log de Linux... 9 Ed. 02 / 26-11-2003 1 TC0296

OmniPCX 4400/Enterprise RELEVÉ D'INFORMATIONS EN CAS DE 4.9. Fichiers log du système... 9 4.10. Liste des cartes de l'installation... 10 4.11. Configuration du système... 10 4.12. Type de CPU... 10 4.13. Références de la CPU... 10 4.14. Détection d'une corruption mémoire... 10 TC0296 2 Ed. 02 / 26-11-2003

RELEVÉ D'INFORMATIONS EN CAS DE OmniPCX 4400/Enterprise 1. INTRODUCTION Cette communication technique fournit des trucs et astuces concernant des problèmes CPU tels que redémarrage, arrêt de l'application téléphone ou impossibilité de se connecter au système. Si aucune solution n'est trouvée, un contrôle du matériel devra être effectué. Si la solution n'est toujours pas trouvée, une demande de service (Service Request) de type "Fiche d'observation" (Observation Sheet) devra être ouverte par le Business Partner. La Fiche d'observation devra contenir des informations dont la liste est donnée à la fin de ce document. De nombreux fichiers log sont stockés sur le système. Chaque reset du système remplacera les anciens fichiers log par des nouveaux. Les fichiers log concernant un problème particulier devront être sauvegardés le plus rapidement possible avant que les informations ne soient perdues. 2. TRUCS ET ASTUCES SUR LES 2.1. Qui a initialisé le redémarrage du système? 2.1.1. Redémarrage automatique Éditer les fichiers texte : /DHS3dyn/incid/incpbm.1, /DHS3dyn/incid/incpbm.2 /DHS3dyn/incid/incpbm.3. La ligne qui contient mailsys asks shutdown signifie que le logiciel a lancé un redémarrage luimême. Il n'y a pas eu d'action manuelle pour lancer le shutdown. 0005 Fri Jan 25 15:42:30 2002 mailsys asks 'echo `ps wc -l` processes running&' 0006 Fri Jan 25 15:42:30 2002 mailsys asks 'shutdown &' at 25/01/02 15:42:30 ; S 0007 Fri Jan 25 15:42:31 2002 mailsys asks 'echo `ps wc -l` processes running&' Dans ce cas, la liste des incidents contiendra un incident de gravité 0 qui confirmera le redémarrage. Le redémarrage a été lancé, suite à des problèmes détectés sur le système. La cause des dysfonctionnements peut aussi être indiquée dans la liste des incidents. Note Lors de l'analyse des incidents système, vérifier qu'il n'y a pas de filtre et que tous les incidents sont affichés. Des incidents de gravité inférieure peuvent indiquer la cause du redémarrage. Ed. 02 / 26-11-2003 3 TC0296

OmniPCX 4400/Enterprise RELEVÉ D'INFORMATIONS EN CAS DE 2.2. Le téléphone s'arrête Le téléphone s'est arrêté. Il n'y a pas d'accès V24 ou IP. L'écran du port console est vide. Essayer de générer un crashdump manuellement. Le crashdump est une copie de la mémoire du système. Le fichier du crashdump doit être fourni avec la fiche d'observation. La capture de texte doit être jointe à la fiche d'observation et au fichier crashdump ; se reporter à la communication technique TC0500 Utilisation simplifiée du kernel debugger sous Chorus et Linux pour la façon de générer un crashdump et d'extraire le fichier crashdump. 2.3. Une CPU redémarre continuellement 2.3.1. Problème avec la configuration IO2 Si des cartes IO2/IO2N sont présentes, vérifier que la gestion de ces cartes est correcte et identique sur les CPU Main et Stand-By. Après le redémarrage de la CPU, arrêter le lancement du téléphone. À partir de la version C1.712, les commandes ci-dessous permettent de consulter et de modifier la gestion des cartes IO2 même si le téléphone est arrêté : login : mtcl a4400> RUNMAO a4400> mgr 2.3.2. Problème avec la carte IO2 Quand la carte IO2 est présente et gérée, elle joue le rôle de commutation. Elle remplace l IO1 embarquée dans la CPU. Lorsque des redémarrages sont inexpliqués, il peut être intéressant, pour test, de la remplacer par une carte IO2N si c est possible ; comme le logiciel est différent, la réaction du système sera aussi différente et pourra fournir des informations sur le défaut initial. Joindre le résultat de ce test dans la fiche d'observation. Note L IO2N n est prise en compte qu à partir de certaines versions logicielles ; se reporter à la communication technique TC0192 - Procédure de mise en service des cartes IO2N. Quand une carte IO2 ou IO2N est installée avec une CPU, le même type de carte IO2 doit être installé sur la CPU dupliquée (si présente). 2.3.3. Reboot CPU lié à l'io2 Certaines configurations avec cartes IO2 et INTOF reliant des noeuds entre eux posent problème. L'IO2 n'est pas assez puissante pour traiter tous les messages. Elle se "resette" et provoque le reboot de la machine. TC0296 4 Ed. 02 / 26-11-2003

RELEVÉ D'INFORMATIONS EN CAS DE OmniPCX 4400/Enterprise Les incidents liés à ce défaut sont du type : 1608 : Plus de place pour stocker les messages 1621 : Driver IO2 : plus de mémoire pour émettre 1722 : Tache abortée 2998 : Commutateur de paquets aborté 3139 : IO2 Problème chemin de sig Faire un appel Hot Line pour investigation. 2.3.4. Problème avec des fichiers OPS Normalement, les mêmes fichiers OPS sont installés sur les deux CPU. Si ce n'est pas le cas et si le champ PARA_MAO 1 du fichier hardware.mao est différent, il peut se produire un redémarrage permanent de la CPU avec les incidents 2076 ou 2070: 2076 = Région du TEL ou des rémanents différentes sur CPU principale et secours ou pour les Releases 1.4/2.x : 2070 = Mode de swap différents sur CPU principale et secours Ce cas peut se produire lors de l'installation de nouveaux fichiers OPS sur la CPU Stand By, s'il y a une modification de la taille des données rémanentes. Dans ce cas, le téléphone doit être complètement arrêté pour installer les nouveaux fichiers OPS sur les deux CPU. 2.4. Corruption de la base de données Dans le cas d'une corruption de la base de données, des incidents peuvent être stockés dans le fichier incidents. Vous pouvez utiliser les commandes suivantes pour vérifier la base de données : a4400> cd /DHS3data/mao a4400> checkinitrem Si une corruption de la base de données est suspectée, vous devez restaurer une sauvegarde de la base de données. Dans les versions récentes, une sauvegarde automatique de la base de données est effectuée tous les jours sur le disque dur. Pour restaurer une sauvegarde de la base de données, utiliser les commandes ci-dessous : login : swinst Option 4 : Select Save & Restore operations Option 4 : Select Restore operations Option 2 : Select Restore from cpu disk Choisir un fichier de sauvegarde parmi ceux présents sur le disque. Ed. 02 / 26-11-2003 5 TC0296

OmniPCX 4400/Enterprise RELEVÉ D'INFORMATIONS EN CAS DE 2.5. Contrôle de l'installation de la version logicielle Le test d'intégrité vérifie que la version logicielle a été correctement installée sur la CPU. Pour cela, taper les commandes suivantes : login : swinst Option 8 : Software identity display Option 6 : Application software validity checking Sélectionner la partition à contrôler. Contrôler le résultat du test d'intégrité. Si problème il y a (affichage d'un message de type "Checksum incorrect"), le logiciel devra être rechargé. 2.6. Contrôle des ports V24 En cas de présence de CPU3 : si un modem ou TA est connecté à un port V24 avec un login, il ne doit pas être géré comme suit : des codes Hayes de réponse aux commandes et l écho local pour un modem, un menu d accueil sur TA, vérifier la présence d une application client qui dialoguerait avec un port V24 de la CPU, une boucle peut se produire si le port V24 de la CPU est géré avec un login. Le système risque de redémarrer. Astuce Taper la commande ci-dessous pour vérifier l'activité des ports V24 : a4400> sar y 1 <nb> (ou <nb> = nombre de "scan" sur le port ; exemple : 20 ) Le paramètre 1 signifie un scan toutes les secondes. Cette commande fournit le nombre d'octets émis/reçus sur les ports série. (410)xa004010> sar -y 1 20 Chorus xa004010 MiX V.3.2r4.1.5 r4.1.5 COMP-386 01/25/102 15:25:18 rawch/s canch/s outch/s rcvin/s xmtin/s mdmin/s 15:25:19 0 0 124 0 124 0 15:25:20 0 0 58 0 58 0 15:25:21 0 0 58 0 58 0 15:25:22 0 0 58 0 58 0 etc. jusqu à 20 lignes Surveiller le champ outch/s ; il donne le nombre de caractères émis sur tous les ports V24. 2.7. Capture d'informations systèmes En cas de problèmes CPU fréquents et sans aucune explication, démarrer une capture de texte permanente sur le terminal Windows du PC connecté sur le port console. Les messages systèmes ne sont pas stockés et ne sont édités que sur ce port. Cette trace est à joindre à la fiche d'observation. TC0296 6 Ed. 02 / 26-11-2003

RELEVÉ D'INFORMATIONS EN CAS DE OmniPCX 4400/Enterprise 3. INVESTIGATIONS MATÉRIELLES Quand les contrôles logiciels ont été effectués et que le problème est toujours existant, il faut procéder à des investigations sur des éléments matériels tels que : carte CPU : changer la carte CPU par une autre, alimentation, raccordement de la terre, défaut sur la carte ET (située au niveau du voyant en bas à gauche des bâtis), redresseur mal dimensionné, fond de panier, environnement extérieur, etc. 4. INFORMATIONS À RELEVER POUR OUVRIR UNE DEMANDE DE SERVICE Chaque fois qu'il y a un problème CPU sur une version non en "Phase out", que le matériel a été vérifié et que vous ne pouvez pas trouver la cause ou fournir une solution, une fiche d'observation doit être élaborée avec toutes les informations décrites ci-dessous. 4.1. Description du problème La fiche d'observation doit comporter une description détaillée du problème et donner des réponses aux questions suivantes : Le téléphone est-il toujours opérationnel? Y a t-il eu un reset manuel? Y a t-il eu un reset automatique? Le système a t-il résolu le problème lui-même? Quelqu'un a t-il fait quelque chose manuellement pour redémarrer le système? Quel est l'affichage sur les postes UA durant le problème? Ont-ils la tonalité? Pouvez-vous vous connecter durant le problème? Est ce une nouvelle installation? Si c'est un nouveau problème sur un ancien système, quelles modifications ont été effectuées sur l'installation? Quelle est la fréquence du problème? Quand est ce arrivé (date et heure)? La configuration OPS est-elle en conformité avec les besoins fonctionnels du client (trafic, postes fictifs, etc.). 4.2. Description des investigations La fiche d'observation doit indiquer les investigations effectuées sur le site : échange de cartes, remplacement, contrôles, etc. Ces informations éviteront au Support Technique de demander des tests déjà effectués sur site. Ed. 02 / 26-11-2003 7 TC0296

OmniPCX 4400/Enterprise RELEVÉ D'INFORMATIONS EN CAS DE 4.3. Fichiers log des incidents Les fichiers log des incidents sont stockés comme suit : <---------"incidents 2"---------><-------"incidents 1"--------><----"incidents actuels" ------------------ --------------------------------- ------------------------------- --------------------- > temps reboot 2 reboot 1 dernier reboot MAINTENANT Joindre les résultats des commandes suivantes à la fiche d'observation : a4400> incvisu a4400> incvisu -1 a4400> incvisu -2 Vérifier que tous les incidents sont affichés et qu'aucun incident n'est filtré. 4.4. Fichiers log des exceptions téléphone Les fichiers log des exceptions sont stockés comme suit : <--------"exceptions 2"--------><-------"exceptions 1"-------><---"exceptions actuelles" ------------------ --------------------------------- ------------------------------- --------------------- > temps reboot 2 reboot 1 dernier reboot MAINTENANT Joindre les résultats des commandes suivantes à la fiche d'observation : a4400> excvisu a4400> excvisu -1 a4400> excvisu -2 4.5. Fichiers log des black boxes Les fichiers log des black boxes sont stockés sous le répertoire /tmpd comme suit : <--------blackbox.3------><--------blackbox.2---------><------blackbox.1---------><-------blackbox ---- --------------------------- ------------------------------ ---------------------------- ------------------- > temps reboot -3 reboot 2 reboot 1 dernier reboot MAINTENANT Joindre les résultats des commandes suivantes à la fiche d'observation : a4400> readbbox a4400> readbbox -1 a4400> readbbox -2 a4400> readbbox -3 4.6. Fichiers log du téléphone Les fichiers log du téléphone sont stockés sous le répertoire /tmpd comme suit : <----DHS3-INIT.log3----><-----DHS3-INIT.log2------><-----DHS3-INIT.olog----><---DHS3-INIT.log ---- --------------------------- ------------------------------ ---------------------------- ------------------- > temps reboot -3 reboot 2 reboot 1 dernier reboot MAINTENANT TC0296 8 Ed. 02 / 26-11-2003

RELEVÉ D'INFORMATIONS EN CAS DE OmniPCX 4400/Enterprise Joindre la copie des quatre fichiers texte à la fiche d'observation : /tmpd/dhs3-init.log, /tmpd/dhs3-init.olog, /tmpd/dhs3-init.log2, /tmpd/dhs3-init.log3. 4.7. Fichiers log de Chorus Les fichiers log de Chorus sont stockés sous le répertoire /etc comme suit : -------boot.log3-----><------------boot.log2----------><----------- boot.log1--------><------- boot.log ------------------ --------------------------------- ------------------------------- --------------------- > temps reboot 2 reboot 1 dernier reboot MAINTENANT Joindre les résultats de la commande suivante à la fiche d'observation : a4400> traceboot v 4.8. Fichiers log de Linux Récupérer les fichiers de type "messages" et "syslog" sous /var/log. login : root commande: cp messages* /tmpd et cp syslog* /tmpd : cd /tmpd : tar zxvf <fichier_final> messages* syslog* Joindre <fichier_final> à la fiche d'observation. Note La commande précédente compresse et crée un seul fichier contenant tous les fichiers messages et syslog. Supprimer ces fichiers dans /tmpd au final. 4.9. Fichiers log du système Les fichiers log du système sont stockés sous le répertoire /DHS3dyn/incid comme suit : ----incpbm.3-----<-----------incpbm.2------------><----------incpbm.1----------><----------incpbm ------------------ --------------------------------- ------------------------------- --------------------- > temps reboot 2 reboot 1 dernier reboot MAINTENANT Joindre la copie des trois fichiers texte à la fiche d'observation : /DHS3dyn/incid/incpbm.1, /DHS3dyn/incid/incpbm.2, /DHS3dyn/incid/incpbm.3. Ed. 02 / 26-11-2003 9 TC0296

OmniPCX 4400/Enterprise RELEVÉ D'INFORMATIONS EN CAS DE 4.10. Liste des cartes de l'installation Pour chaque alvéole de chaque nœud, joindre les résultats de la commande suivante à la fiche d'observation : a4400> config x (x = numéro d'alvéoles) ou config all v (ne pas oublier les cartes virtuelles) 4.11. Configuration du système Indiquer : le nombre de nœuds, la configuration réseau, la configuration CCD, le nombre d'usagers, la présence d'applications externes telles que cartes de type "CMP", etc., 4.12. Type de CPU Joindre les résultats de la commande suivante à la fiche d'observation : a4400> uhwconf 4.13. Références de la CPU Indiquer sur la fiche d'observation les références techniques complètes de : la carte CPU, la mémoire, disque dur, la carte processeur. La carte CPU doit être défichée pour lire les références des différents éléments. 4.14. Détection d'une corruption mémoire Joindre les résultats des commandes suivantes à la fiche d'observation : login : root a4400 > /usr2/oneshot/mtch/memcheck En cas de corruption mémoire, des messages de type Segment corrupted seront affichés. TC0296 10 Ed. 02 / 26-11-2003