Introduction
Ce document décrit comment identifier un arrêt inattendu d'une application sur le système d'exploitation vocal (VOS) personnalisé de Cisco.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Cisco Unified Communications Manager (CUCM), Cisco Unity Connection (CUC), Cisco Unified Contact Center Express (UCCX), Cisco Emergency Responder (CER) et Cisco Prime sont considérés comme des applications UC.
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 corrompu.
Afin de récupérer temporairement le système, exécutez le disque de récupération du système libéré pour la version du logiciel correspondant.
Vérifier un arrêt incorrect
Consultez le fichier system-history.log afin de déterminer si un système a été arrêté de manière incorrecte.
Remarque : le fichier history.log a été amélioré afin de suivre les arrêts incorrects avec l'ID de bogue Cisco CSCtr8859 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 et de mise à niveau à partir de l'outil Cisco Unified Real-Time Monitoring Tool (RTMT) et collectez le fichier 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 root : Boot et vérifiez 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 poursuivie par un redémarrage, un arrêt, une installation ou une mise à niveau, il est probable qu'un arrêt incorrect 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 de garantir la cohérence du système de fichiers. Consultez ces ID de bogue Cisco pour plus de détails :
- ID de bogue Cisco CSCth60800, « Avertissement de disque de récupération pour reconstruire le système après la réparation du système de fichiers »
- ID de bogue Cisco CSCth53322, « Documentation de la nécessité de reconstruire le système après la réparation du système de fichiers »
- ID de bogue Cisco CSCuy94644, « Corruption de Cisco Emergency Responder après un arrêt inattendu »
Remarque : si le serveur s'exécute sur VMware sur une version sans le correctif pour l'ID de bogue Cisco CSCtw73590, « VSphere initiated shutdown or restart not log to system-history.log » et si le serveur est arrêté via VSphere quand un arrêt invité est initié, cette entrée n'est pas incluse dans system-history.log.
Commentaires