簡介
本文說明如何識別思科自訂語音作業系統(VOS)之上的任何應用意外關閉。
必要條件
需求
本文件沒有特定需求。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
Cisco Unified Communications Manager(CUCM)、Cisco Unity Connection(CUC)、Cisco Unified Contact Center Express(UCCX)、Cisco Emergency Responder(CER)和Cisco Prime均被視為統一通訊應用。
如果伺服器發生意外關機，則無法保證檔案系統的一致性。檔案可能會意外刪除，檔案許可權的所有權可能會更改，或者檔案內容可能損壞。
為了臨時恢復系統，請運行為相應的軟體版本發佈的系統恢復磁碟。
驗證不正確的關機
檢視system-history.log以確定系統是否關閉不當。
註：為了使用Cisco錯誤ID CSCtr8859跟蹤不正確的關機，增強了history.log，以便為CUCM 9.1(1)及更新版本中整合的意外重新啟動新增警報和警報。
- 從思科統一即時監控工具(RTMT)下載安裝/升級日誌，並收集system-history.log。
或
在命令列介面(CLI)上輸入file view install system-history.log命令。
- 檢查root:Boot的每個例項，並確認每個例項前面都包含以下行之一：
root: Restart
root: Shutdown
root: Install
root: Upgrade
- 如果重新啟動、關機、安裝或升級沒有繼續引導例項，則可能是非乾淨關閉。
以下是不乾淨關閉的範例：
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
在本示例中，必須重建伺服器以確保檔案系統的一致性。如需進一步的詳細資訊，請參閱以下思科錯誤ID:
- 思科錯誤ID CSCth60800，「Recovery Disk warning to rebuild system after file system repair」（檔案系統修復後恢復磁碟警告以重建系統）
- 思科錯誤ID CSCth53322，「記錄檔案系統修復後系統重建的需要」
- 思科錯誤ID CSCuy94644，「Cisco Emergency Responder corruption after unexpected shutdown（意外關機後思科緊急響應程式損壞）」
註：如果伺服器在VMware上運行且版本未修復Cisco錯誤ID CSCtw73590，「VSphere initiated shutdown or restart not logged to system-history.log」，並且如果伺服器在啟動來賓關閉時通過VSphere關閉，則該條目不會包含在system-history.log中。
意見