Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Comment identifier un arrêt inattendu d'un serveur CUCM, UC, ou UCCX

15 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment identifier un arrêt inattendu d'un serveur du Cisco Unified Communications Manager (CallManager) (CUCM), du Cisco Unified Communications (UC), ou du Cisco Unified Contact Center Express (UCCX). Si un serveur CUCM, UC, ou UCCX éprouve un arrêt inattendu, la cohérence de système de fichiers ne peut pas être garantie. Des fichiers peuvent être retirés inopinément, la propriété des permissions du fichier peut être changée, ou le contenu des fichiers pourrait être corrompu.

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

Contribué par Adam Frankel, ingénieur TAC Cisco.

Vérifiez l'arrêt inexact

Passez en revue system-history.log afin de déterminer si un système a été arrêté incorrectement.

Remarque: Tout system-history.log a été ajouté en tant qu'élément de l'ID de bogue Cisco CSCsl94283, « CCM 5.X devrait dépister installent/mises à jour avec History.log comme des versions de 4.X." dans des versions antérieures n'ont pas été dépistés. History.log a été amélioré afin de dépister des arrêts inexacts avec l'ID de bogue Cisco CSCtr88859 afin d'ajouter des alarmes et des alertes pour les réinitialisations inattendues qui sont intégrées dans des versions 9.1(1) et ultérieures CUCM.

  1. Téléchargez les logs d'installer/mise à jour de l'outil de suivi en temps réel de Cisco Unified (RTMT), et recueillez system-history.log.
    ou
    Écrivez l'affichage de fichier installent la commande de system-history.log sur l'interface de ligne de commande (CLI).

  2. Examinez chaque exemple de racine : Démarrez, et confirmez que chaque exemple est précédé par une de ces lignes :

    root: Restart
    root: Shutdown
    root: Install
    root: Upgrade
  3. Si un exemple de démarrage n'est pas poursuivi par une reprise, l'arrêt, installent, ou améliorent, là étaient probable un arrêt malpropre.

C'est un exemple d'un arrêt malpropre :

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 de système de fichiers. Voir les ces id de bogue Cisco pour d'autres détails :

  • ID de bogue Cisco CSCth60800, « avertissement de disque de reprise de reconstruire le système après la réparation de système de fichiers »
  • L'ID de bogue Cisco CSCth53322, « documentent le besoin de reconstruction de système après que la réparation de système de fichiers »

Remarque: Si le serveur s'exécute sur le VMware sur une version sans difficulté pour l'ID de bogue Cisco CSCtw73590, « VSphere a initié l'arrêt ou la reprise non connectée à system-history.log » et si le serveur est arrêté par VSphere quand un arrêt d'invité est initié, que l'entrée ne peut être incluse dans system-history.log.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116717