Comment identifier un arrêt inattendu d'un CUCM, UC, UCCX, CER ou Cisco Prime Server

Options de téléchargement

PDF (114.6 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (86.0 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (72.2 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:13 mai 2016

ID du document:116717

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

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.

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).
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
```
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.