Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Cómo identificar un cierre inesperado de un servidor CUCM, UC, o UCCX

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe cómo identificar un inesperado apaga de un servidor del Cisco Unified Communications Manager (CallManager) (CUCM), de las Comunicaciones unificadas de Cisco (UC), o del Cisco Unified Contact Center Express (UCCX). Si un servidor CUCM, UC, o UCCX experimenta un inesperado apague, el estado coherente del sistema de archivos no puede ser garantizado. Los archivos se pueden quitar inesperado, la propiedad de los permisos del archivo puede ser cambiada, o el contenido de los archivos pudo ser corrompido.

Para recuperar temporalmente el sistema, ejecute el disco de la recuperación del sistema liberado para la versión de software correspondiente.

Contribuido por Adán Frankel, ingeniero de Cisco TAC.

Verifique el apagado incorrecto

Revise system-history.log para determinar si un sistema se ha apagado incorrectamente.

Nota: system-history.log fue agregado como parte del Id. de bug Cisco CSCsl94283, “CCM 5.X debe seguir todo instala/actualización con History.log como las versiones del 4.X." en las versiones anteriores no fue seguido. History.log fue aumentado para seguir los apagados incorrectos con el Id. de bug Cisco CSCtr88859 para agregar las alarmas y las alertas para las reinicializaciones inesperadas que se integran en las versiones CUCM 9.1(1) y posterior.

  1. Descargue los registros del instalar/de la actualización de la herramienta unificada Cisco del monitoreo en tiempo real (RTMT), y recolecte system-history.log.
    o
    Ingrese la opinión del archivo instalan el comando de system-history.log en el comando line interface(cli).

  2. Examine cada caso de la raíz: Inicie, y confirme que cada caso es precedido por una de estas líneas:

    root: Restart
    root: Shutdown
    root: Install
    root: Upgrade
  3. Si un caso del inicio no es procedido por un reinicio, apague, instale, o actualice, allí era probable un sucio apagan.

Éste es un ejemplo de un sucio apaga:

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

En este ejemplo, el servidor se debe reconstruir para asegurar el estado coherente del sistema de archivos. Vea este bug Cisco ID para otros detalles:

  • Id. de bug Cisco CSCth60800, “advertencia del disco de la recuperación de reconstruir el sistema después de la reparación de sistema de archivos”
  • El Id. de bug Cisco CSCth53322, “documenta la necesidad de la reconstrucción del sistema después de la reparación de sistema de archivos”

Nota: Si el servidor se está ejecutando en VMware en una versión sin el arreglo para el Id. de bug Cisco CSCtw73590, “VSphere inició apaga o recomienza no registrado a system-history.log” y si el servidor se apaga con VSphere cuando se inicia un invitado apaga, que la entrada no se puede incluir en system-history.log.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 116717