Contenu

Introduction

Vérifier l'arrêt incorrect

Introduction

Ce document décrit comment identifier un arrêt inattendu d'un Cisco Unified Communications Manager (CallManager) (CUCM), Cisco Unity Connection (UC), Cisco Unified Contact Center Express (UCCX), Cisco Emergency Responder (CER), Cisco Prime ou toute application qui s'exécute sur le système d'exploitation vocal personnalisé (VOS) de Cisco. Si le serveur subit un arrêt inattendu, la cohérence du système de fichiers ne peut pas être garantie. Les fichiers peuvent être supprimés de manière inattendue, la propriété des autorisations de fichier peut être modifiée ou le contenu des fichiers peut être endommagé.

Afin de récupérer temporairement le système, exécutez le disque de récupération système libéré pour la version logicielle correspondante.

Vérifier l'arrêt incorrect

Examinez system-history.log afin de déterminer si un système a été arrêté de manière incorrecte.

Note: Le system-history.log a été ajouté dans l'ID de bogue Cisco CSCsl94283, « CCM 5.X devrait suivre toutes les installations/mises à niveau avec History.log comme 4.X. » Les versions des versions précédentes n'ont pas été suivies. Le fichier history.log a été amélioré afin de suivre les arrêts incorrects avec l'ID de bogue Cisco CSCtr88859 afin d'ajouter des alarmes et des alertes pour les redémarrages inattendus qui sont intégrés dans CUCM versions 9.1(1) et ultérieures.

1. Téléchargez les journaux d'installation/de mise à niveau à partir de l'outil de surveillance en temps réel Cisco Unified (RTMT) et rassemblez system-history.log.

ou

Entrez la commande file view install system-history.log sur l'interface de ligne de commande (CLI).

2. Examinez chaque instance de racine : Démarrez et confirmez que chaque instance est précédée de l'une des lignes suivantes :

root: Restart

root: Shutdown

root: Install

root: Upgrade

3. Si une instance de démarrage n'est pas exécutée par un redémarrage, une arrêt, une installation ou une mise à niveau, il est probable qu'un arrêt non nettoyé s'est produit.

Voici un exemple d'arrêt non nettoyé :

08/14/2012 13:36:09 | root: Boot 9.0.1.10000-37 Start

08/14/2012 17:28:25 | root: Boot 9.0.1.10000-37 Start

Dans cet exemple, le serveur doit être reconstruit afin d'assurer la cohérence du système de fichiers. Pour plus d'informations, reportez-vous aux ID de bogue Cisco suivants :

- ID de bogue Cisco CSCth60800, « Récupération de l'avertissement de disque pour reconstruire le système après réparation du système de fichiers »

- ID de bogue Cisco CSCth53322, « Documenter la nécessité d'une reconstruction du système après réparation du système de fichiers »

- ID de bogue Cisco CSCuy94644, « Corruption de Cisco Emergency Responder après arrêt inattendu »

Note: Si le serveur s'exécute sur VMware sur une version sans le correctif pour l'ID de bogue Cisco CSCtw73590, « VSphere a initialisé shutdown ou restart not logging to system-history.log » et si le serveur est arrêté par VSphere lors d'un arrêt invité, cette entrée peut ne pas être incluse dans system-history.log.