前端時間有人問我小型機出現故障之後怎麼去找問題,但是之前出差比較忙,今天我就好好的将這個整理一下。希望大家看到之後有什麼不到位的地方可以補充下。
第一、先定義故障
弄清楚系統發生了什麼問題
系統現在能做什麼?不能做什麼?
故障什麼時候發生的?
有沒有做平時不同的操作?
故障有沒有規律?定時還是不定時?發生的頻率有多高?
是一台機器出現故障還是多台機器故障?故障現象是否相同?
最近有沒有做改動?如安裝了新的硬體、軟體,改變了系統的一些設定。
第二、對故障進行故障資訊收集
1) 收集故障資訊對于判斷、診斷故障原因,修複系統非常重要。
2) 系統故障記錄(errorlog)
errdemon 程序在系統啟動時自動運作
記錄包括硬體、軟體及其他操作資訊
故障記錄檔案為/var/adm/ras/errlog,可備份下來或拷貝到别的機器上分析
errpt 指令的使用(普通使用者權限也可使用)
# errpt |more 列出簡短出錯資訊
3) 控制台上的LED 代碼
8 位代碼,通常系統故障燈會同時亮起。某些機型還會同時顯示故障裝置位置代碼。
4 位代碼,通常是Exxx。
3 位代碼,通常為0yyy,隻看後3位。
8 位和4位代碼可檢視系統服務手冊 (Service Guide)。
4) SMS (System Management Service) 故障記錄
如何進入SMS 菜單
當主要台出現鍵盤圖示後(LED 顯示E1F1時)按1鍵。
選擇"Utilities",選擇"Error Log", 抄下8位故障代碼(在SMS 中還可以更改系統啟 動順序表)
5) MAIL
系統會向root使用者發mail報告出錯資訊。通常系統出現故障後沒有進行檢查修複,系統會定時提醒root。
6) 運作故障診斷程式(Diagnostic),對系統硬體進行檢查和診斷。
當發現有硬體故障時應立即使用diag
#diag
> 選進階診斷(Advance Diagnostic)
> 選問題診斷(Problem Determination) 或 選系統檢查(System Verification)
(選PD 會對系統錯誤記錄進行分析)
diag運作後會給出SRN 代碼,故障裝置名稱及百分比,位址代碼等。
對于PCI機型應在系統報錯7天之内運作diag程式對出錯記錄裡的sense資料進行分析。
7) 其他用于收集系統資訊的指令
lsdev -C 系統裝置資訊
lspv 檢視實體卷資訊 還有其他的。。。
第三、硬體故障定位
IBM 小型機故障定位方法包括小型機I/O櫃上的顯示面闆上的Checkpoints資訊,Error Code 和SRNs。
Checkpoints 檢查點是系統加電CMOS初始化程式(initial program load (IPL))運作後顯示在 I/O櫃的顯示面闆上一系列資訊。
1. IPL 流程
當交流電源接到系統後,IPL流程就開始了,IPL流程包括四個步驟:
. Phase 1: Service Processor 的初始化
Phase 1 開始于交流電源接到系統後,直到OK顯示在I/O櫃上的顯示面闆上為止。在這個步驟會顯示 8xxx 或9xxx checkpoints代碼 。
. Phase 2: 由 Service Processor 引導的硬體初始化
Phase 2 開始于按下I/O櫃上的白色電源開關。在這個步驟會顯示 9xxx checkpoints 。91FF 是最後的代碼标志着第三步驟的開始
. Phase 3: 系統固件的初始化
在 Phase 3, 一個系統處理器接管控制并繼續初始化系統資源, 在這個步驟會顯示 Exxx。E105是最後的代碼标志着第四步驟AIX啟動的開始。在這個過程中還會顯示各種位置碼( 位置碼代表着系統的每一個部分)
. Phase 4: AIX 啟動
當AIX開始啟動時,顯示面闆上的代碼為 0xxx ,同時位置碼會出現在第二行。當AIX的登入視窗出現在控制台上時第四步驟結束同時顯示面闆上再無任何資訊出現。
Error Code 當系統運作有錯誤發現時,一個8位碼會顯示在顯示面闆上,同時在第二行顯示相對應問題硬體的位置碼。
SRNs (Service request numbers,服務請求碼 )當系統運作有錯誤發現時,SRNs碼會以 xxx-xxx的形式顯示在顯示面闆上,同時在AIX的error log中也會有記載。
以上所有代碼都會有相應的步驟解決。由于代碼繁多,請在出現問題後記錄下代碼,并緻電IBM服務熱線。
2. 系統不能啟動
系統停在Stage 1,可能為電源、系統闆、CPU、記憶體等硬體故障。記錄故障代碼通知IBM工程師。
系統停在Stage 2,可能是啟動順序表(bootlist)損壞或I/O子系統故障。可嘗試進入SMS 菜單檢查啟動順序表,并修改。若在選擇bootlist時沒有硬碟裝置可選或顯示的硬碟資訊不正确則可能是硬碟故障。若根本沒有SCSI裝置可選則鍊路有問題。
系統停在Stage3,可能是硬碟資料損壞,系統設定檔案出錯,或I/O子系統故障。
系統停在551,555或557
發生在系統啟動的第三階段 (Stage 3),可能是:
檔案系統損壞
檔案系統日志(jfslog)損壞
rootvg中有壞硬碟
3. 修複方法
用系統CD光牒或系統備份帶啟動(必須與硬碟中的作業系統版本一緻)
啟動後選擇選項3
"Start Maintenance Mode for System Recovery"
> "Access a Root Volume Group"
> "Access this volume group and start a shell
before mounting the file systems"
格式化檔案系統日志(jfslog)
# /usr/sbin/logform /dev/hd8
檢查修複檔案系統
# fsck -y /dev/hd1 (/home 檔案系統)
# fsck -y /dev/hd2 (/usr 檔案系統)
# fsck -y /dev/hd3 (/tmp 檔案系統)
# fsck -y /dev/hd4 (/ 檔案系統)
# fsck -y /dev/hd9var (/var 檔案系統)
... ...
用 exit 指令退出,檔案系統會自動 mount 起來。
重建bootimage
# lslv -m hd5 找出bootimage所在的硬碟,如hdisk0
# bosboot -ad /dev/hdisk0
# bootlist -m normal /dev/hdisk0 重建啟動順序表。
重新開機動系統
# shutdown -Fr
如上述步驟不奏效
用系統備份帶恢複系統。
如備份帶不能恢複,用診斷CD光牒(Diagnostic CDROM)檢查是否壞硬碟。
4. CDE圖形界面挂死
CDE 運作時不要更改網絡參數(如:主機名和IP 位址)
更改網卡設定,請先退出CDE圖形環境,選擇指令行方式登入,在字元界面下更改。
如CDE 已經挂死
遠端 telnet 登入
找出所有dt有關的程序用kill指令殺掉
# ps -ef |grep dt
# kill PID
檢查目前主機名
# hostname
tscf50
檢視主機名是否對應有效的IP位址
# netstat -i |grep tscf50
tr0* 1500 9.185.40 tscf50 506049 0 28247 0 0
更改主機名或IP位址,使主機名與目前有效的IP位址存在對應關系。
# smitty tcpip
重新啟動CDE界面
# /etc/rc.dt
HACMP環境下可把主機名alias到127.0.0.1上
# cat /etc/hosts
127.0.0.1 loopback localhost tscf50 # loopback (lo0) name/addressbvg
5. 系統dump
發生在系統崩潰時,AIX會做dump(系統記憶體的快照)。
此時機器會顯示閃動的888 102 xxx 0cx 代碼:
0c9 系統dump 進行中。0c9狀态可能會維持超過2分鐘,
不要關電和按reset, 等待dump做完。
0c0 dump 成功完成,這時可以斷電重起。
0c2 手動啟動dump 功能
0c4 dump 裝置空間不足,隻有部分資訊儲存下來
0c5 不明原因導緻dump 失敗
一般dump是由于軟體出錯引起(888-102-207 除外),機器通常可以重新開機。重新開機時可能提示使用者插入錄音帶拷貝dump檔案,不要選擇退出,這樣會丢失重要的故障資訊。
dump的有關設定
估算系統dump的大小,在系統最繁忙時(記憶體使用最多)
# sysdumpdev -e
0453-041 Estimated dump size in bytes: 53477376
# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
paging00 hdisk0 rootvg 480MB 1 yes
hd6 hdisk1 rootvg 544MB 1 yes
目前的設定
#sysdumpdev -l
primary /dev/hd6
第四、軟體故障的定位
軟體故障情況錯綜複雜,下面列舉幾個常見案例的故障處理方法。
1) 檔案系統空間不夠。
檢視有沒有“滿”的檔案系統。特别是/、/var、/tmp,不要超過90%。檔案系統滿可導緻系統不能正常工作,尤其是AIX的基本檔案系統。如/ (根檔案系統)滿則會導緻使用者不能登入。用df –k 檢視。
# df -k (檢視AIX的基本檔案系統)
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 24576 1452 95% 2599 22% /
/dev/hd2 614400 28068 96% 22967 15% /usr
/dev/hd9var 8192 4540 45% 649 32% /var
/dev/hd3 167936 157968 6% 89 1% /tmp
/dev/hd1 16384 5332 68% 1402 35% /home
除/usr檔案系統,其他檔案系統都不應太滿,一般不超過80%。
處理方法1:删除垃圾檔案
# du -sk * |sort -rn |head
查找出目前目錄下占空間最大的子目錄,逐層往下直到找出占空間最大的檔案。(要區分哪些目錄是檔案系統的 mount point,哪些是檔案系統的子目錄)删除檔案,釋放空間。有時删除檔案後空間并不馬上釋放,這是由于你删除的檔案正被某個程式打開。隻有當這個程式停止後空間才釋放,有時甚至需要重起系統。
處理方法2:增加檔案系統大小
# smitty chjfs
檔案系統可以在任何時候加大,前提是卷組(VG)中有剩餘空間。
2) 檢查檔案系統的完整性
# umount filesystem_name
# fsck -y filesystem_name
注意:檔案系統必須先umount,再做檢查和修複,否則可導緻未
知的後果。
3) 檢視卷組資訊(lsvg -l vg_name):
有沒有"stale"狀态的邏輯卷。 若有,用syncvg 指令修複"stale"邏輯卷。
4) 檢查記憶體交換區(paging space)使用率(lsps -s):
使用率是否超過70%,若有則用chps –sX pgname增加X個PP或用 mkps –a –n –sX myvg在myvg上增加一個PP數為X的記憶體交換區。
5) 小型機記憶體洩漏問題
小型機出現記憶體洩漏,即系統或應用程序無法将使用過的記憶體釋放,使可用記憶體的容量逐漸減少。如果可用記憶體降到某最小值将造成系統或應用程式無法FORK子程序,就會造成系統癱瘓。
通常我們可以用ps和sar指令來檢視小型機記憶體和CPU占用率的大概情況以及各程序的記憶體和CPU占用率的發展趨勢。
第五、HACMP環境下的排錯
在一般情況下,HACMP軟體很少需要手工幹預,但一旦有問題發生,診斷和恢複的技巧是很重要的.需要能很快地斷定問題然後運用你對HACMP的了解來恢複HACMP的正常運作.
一般地,HACMP環境下的排錯包括:
了解問題的存在.
判斷問題的出處.
解決問題.
第六、常用的系統狀态查詢指令
# lsdev –C –s scsi
列出各個SCSI裝置的所有相關資訊:如邏輯單元号,硬體位址及裝置檔案名等。
# ps -ef
列出正在運作的所有程序的各種資訊:如程序号及程序名等。
# netstat -rn
列出網卡狀态及路由資訊等。
# netstat -in
列出網卡狀态及網絡配置資訊。
# df -k
列出已加載的邏輯卷及其大小資訊。
# mount
列出已加載的邏輯卷及其加載位置。
# uname -a
列出系統ID 号,系統名稱,OS版本等資訊。
# hostname
列出系統網絡名稱。
# lsvg –l rootvg,lsvg –p rootvg
顯示邏輯卷組資訊,如包含哪些實體盤及邏輯卷等。
# lslv –l datalv,lslv –p datalv
顯示邏輯卷各種資訊,如包含哪些盤,是否有鏡像等。
八 網絡故障定位方法
網絡不通的診斷過程:
ifconfig 檢視網卡是否啟動 (up)
netstat –i 檢視網卡狀态
Ierrs/Ipkts 和 Oerrs/Opkts是否>1%
ping自己網卡位址 (ip 位址)
ping其它機器位址,如不通,在其機器上用diag檢測網卡是否有問題。
在同一網中, subnetmask 應一緻。
網絡配置的基本方法:
(1) 如需修改網絡位址、主機名等,一定要用 chdev 指令
# chdev –l inet0 –a hostname=myhost
# chdev -l en0 -a netaddr='9.3.240.58' -a netmask=255.255.255.0’
(2) 檢視網卡狀态:# lsdev –Cc if
(3) 确認網絡位址:# ifconfig en0
(4) 啟動網卡:# ifconfig en0 up
(5) 配置路由
有兩種方式加入路由:
永久路由
# chdev -l inet0 -a route=’10.47.0.0’,’9.3.240.59’
臨時路由
# route add 10.47.1.2 9.3.240.59
用指令 netstat -rn 檢視路由表
本文轉自 沐小七 51CTO部落格,原文連結:http://blog.51cto.com/3088522/1043568