1、 AIX 常見(jiàn)故障報(bào)錯(cuò)及解決方案 大多數(shù)情況下，順著報(bào)錯(cuò)順藤摸瓜很快就能找出原因，但總有例外，有些報(bào)錯(cuò)信息或者日志恰恰讓我們南轅北轍。讓我們看看這些案例最終是如何處理的案例1：圖省事，搞出來(lái)個(gè)大麻煩生產(chǎn)中心有幾套VIOS環(huán)境，正常運(yùn)行了1-2年，今日發(fā)現(xiàn)有2套進(jìn)行健康性檢查，發(fā)現(xiàn)執(zhí)行命令就hang在哪里不動(dòng)了，又是內(nèi)存不夠用了。0403-031 The forkfunction failed. There is not enough memory available.好奇怪，到底內(nèi)存被誰(shuí)用了，vios好端端的就這樣了。都這個(gè)樣子，重啟vios分區(qū)吧。重啟完，vios順利登陸，執(zhí)行健康性檢查沒(méi)啥

2、問(wèn)題，可是用nmon看了一下內(nèi)存使用分配了4個(gè)G，使用1個(gè)多G,慢慢慢慢的就看到內(nèi)存使用越來(lái)越大，不一會(huì)4個(gè)G就用完了，重啟其他vios分區(qū)一個(gè)樣子，連換頁(yè)空間都用了。頓時(shí)一頭霧水。到底發(fā)生了什么呢？生產(chǎn)中心有幾套VIOS環(huán)境，正常運(yùn)行了1-2年.突然出現(xiàn)這種問(wèn)題，首先想到的是變更。梳理了近期變更操作，近期新部署了PowerVC,VIOS進(jìn)行了補(bǔ)丁升級(jí)。VIOS2.1升級(jí)到VIOS2.2.3.首先，重啟vios分區(qū)，在內(nèi)存沒(méi)有用完前趕緊檢查那個(gè)進(jìn)程使用的內(nèi)存.排名第一的是vio_daemon,觀察了一會(huì)發(fā)現(xiàn)內(nèi)存一會(huì)就被他占用完了第二，元兇找到了，vio_daemon到底是干啥的，問(wèn)問(wèn)IBM80

3、0吧，IBM回復(fù)問(wèn)我收集一下系統(tǒng)信息。1.ioslevel2./etc/security/limits的輸出反饋后，IBM告訴我，我遇到了bugvios版本和 /etc/security/limits stack = -1完全符合這個(gè)bug特征。其實(shí)這個(gè)bug是可以避免的，我們大多數(shù)實(shí)施AIX的時(shí)候,很容易順手把 /etc/security/limits.都改成-1，在大多數(shù)情況下，沒(méi)啥問(wèn)題，但是就是在這個(gè)版本下就容易遇到這個(gè)問(wèn)題。default: fsize = -1 core = -1 cpu = -1 data = -1 rss = -1 stack = -1 nofiles = -1T

4、he problem can be due to a known issue inVIOS thru with vio_daemon having a memory leak that was fixedat with IV64508,or it could be due to incorrect VIOS settings.AnswerTo check your VIOS level, as padmin, run:$ ioslevelIf your VIOS level is or higher, the problem ma

5、y be due to the VIOShaving incorrect system settings in /etc/security/limits. If thestack size is set to unlimited (stack = -1),this exposes a condition where the system can be allowed to pin as much stackas desired causing vio_daemon to consume a lot of memory.$ oem_setup_envvi /etc/security/limits

6、 -check thedefault stanzadefault:fsize = -1core = -1cpu = -1data = -1rss = -1stack = -1nofiles = -1In some cases, the issue with vio_daemonconsuming high memory is noticed after a VIOS update to 2.2.3.X. However, aVIOS update will NOT change these settings. It is strongly recommended not tomodify th

7、ese default values as doing so is known to cause unpredictableresults. Below is an example of the default values:default:fsize = 2097151core = 2097151cpu = -1data = 262144rss = 65536stack = 65536nofiles = 2000To correct the problem change the setting back to default values.Then reboot the VIOS at yo

8、ur earliest convenience.案例2：裝個(gè)AIX，卻裝出了信任危機(jī)某制造業(yè)用戶(hù)，一個(gè)新項(xiàng)目著急要上線，讓維保廠商工程師趕緊抓緊準(zhǔn)備一個(gè)AIX資源，裝AIX系統(tǒng)按說(shuō)對(duì)ma工程師來(lái)講應(yīng)該輕車(chē)熟路，可是這次裝了好幾遍，AIX系統(tǒng)就是進(jìn)不去。1 懷疑光盤(pán)問(wèn)題，更換好幾張重裝未果，依舊進(jìn)不去2 懷疑AIX版本，更好了兩個(gè)未果3 懷疑硬件，進(jìn)入asm里也沒(méi)啥報(bào)錯(cuò)首先說(shuō)下用戶(hù)設(shè)備的背景信息，設(shè)備采購(gòu)于2012年，“天工計(jì)劃”中的一款產(chǎn)品Power710 和Power730 中的一款，Power710設(shè)備特點(diǎn)：定位應(yīng)用服務(wù)器，價(jià)格便宜，也就是不需要HMC管理，使用串口安裝的IVM部署管理虛擬

9、化環(huán)境。之前這臺(tái)710用作應(yīng)用服務(wù)器。串口部署過(guò)IVM環(huán)境，這次重裝需要注意串口輸出問(wèn)題。所以一定要進(jìn)行如下配置才可以順利進(jìn)入系統(tǒng)第一步：進(jìn)入維護(hù)模式 如果進(jìn)入 Maintenance Mode 步驟就省略了第二步：#export TERM=vt100# smit chtty紅色標(biāo)注的兩行，增加clocal.syncsyncsyncreboot之后就能順利進(jìn)行系統(tǒng)了。案例3：安裝AIX報(bào)出這個(gè)錯(cuò)，新手老手絕對(duì)沒(méi)見(jiàn)過(guò)相信社區(qū)大多數(shù)人都安裝AIX幾十遍甚至上百遍了，但是今天安裝AIX報(bào)出這個(gè)錯(cuò)，新手老手絕對(duì)沒(méi)見(jiàn)過(guò)安裝AIX停在了這里。其實(shí)我也經(jīng)過(guò)了很多各位的排查工作，最終梳理了一下發(fā)現(xiàn)AIX安裝出

10、問(wèn)題，排除硬件介質(zhì)問(wèn)題，多半是配置問(wèn)題，那就按照這個(gè)思路往下走首先，既然是配置就去profile文件里看看。不查不知道，一查問(wèn)題果然找到了有人會(huì)說(shuō)，你居然犯這么低級(jí)的錯(cuò)誤。冤枉啊，這是PowerVC干的怪我背景沒(méi)說(shuō)清楚。這是PowerVC部署aix出現(xiàn)的問(wèn)題.第二，問(wèn)題找到了，那么為什么會(huì)出現(xiàn)問(wèn)題，部署分區(qū)profile配置是在Powervc設(shè)置的，那就去Powervc里找答案吧。問(wèn)題出在了這里.PowerVC納管了很多主機(jī)，每臺(tái)主機(jī)配置不盡相同，當(dāng)初為了省事就配置了vary計(jì)算模板，最大cpu配置成了32。實(shí)際部署AIX時(shí)候，選擇了一臺(tái)低配的power服務(wù)器，CPU配置沒(méi)有32，只有20個(gè)，

11、結(jié)果被PowerVC配置成25.6.就這樣出現(xiàn)了問(wèn)題。反思這個(gè)問(wèn)題，PowerVC,規(guī)劃配置模板，盡量多配置幾個(gè)計(jì)算模板，與服務(wù)器相匹配.避免此類(lèi)問(wèn)題的發(fā)生。通過(guò)這個(gè)問(wèn)題還有第二種解法：kdb模式下 輸入 f，查看堆棧信息，也可以順勢(shì)查到profile配置信息案例4：執(zhí)行l(wèi)srep，詭異報(bào)出Insufficient memory執(zhí)行l(wèi)srep，詭異報(bào)出Insufficient memory檢查vios分區(qū)內(nèi)存使用情況似乎跟內(nèi)存毫無(wú)關(guān)系。首先檢查了其他vios有沒(méi)有這個(gè)問(wèn)題，發(fā)現(xiàn)均沒(méi)有此現(xiàn)象發(fā)生。對(duì)比vios版本及其lsrep輸出，發(fā)現(xiàn)vios版本。都一樣，唯一不同的是出問(wèn)題的這個(gè)vios /v

12、ar/vio/VMLibrary沒(méi)有iso。把幾個(gè)AIX ISO傳到有問(wèn)題的這個(gè)vios /var/vio/VMLibrary下后，再次執(zhí)行l(wèi)srep，成功了案例5：PowerHA給Oracle新增表空間，遭遇memory croedump通過(guò)PowerHA給Oracle新增表空間，使用C-SPOC在線添加LV,開(kāi)始給Datavg添加，很順利，添加了10個(gè)很成功，在繼續(xù)添加新的lv后，居然報(bào)錯(cuò)了. memory croedump.1，內(nèi)存不夠用了嗎.看了一下確實(shí)有點(diǎn)緊張hostA:hostB:2，仔細(xì)看了一下Powerha日志也沒(méi)啥有價(jià)值的信息難道真的是內(nèi)存快用完了導(dǎo)致的。3，由于還要給其他v

13、g新增lv，所以又嘗試了一下給其他vg添加一下lv試試。居然成功了。這個(gè)問(wèn)題從內(nèi)存報(bào)錯(cuò)開(kāi)始容易給人內(nèi)存不足假象，實(shí)際環(huán)境確實(shí)也是內(nèi)存利用率很高，但是定位最終問(wèn)題不是內(nèi)存不足造成的。首先，剛開(kāi)始新增的幾個(gè)lv都順利，后幾個(gè)就失敗了，然后新增其他vg的lv也成功了，這個(gè)時(shí)候就開(kāi)始懷疑遇到bug了。第二，一般裸奔的powerha，遭遇bug的可能性比較大，檢查一下powerha補(bǔ)丁情況吧果然，基本上就是一個(gè)裸奔的Powerha環(huán)境，遇到bug也就不足為奇了第三，既然懷疑是bug，那就找點(diǎn)說(shuō)服力的東西出來(lái).如下所示IV36992: CLPASSWDREMOTE CORE DUMPS DUE TOMEM

14、ORY FAULTA fix is availableObtain the fix forthis APAR.Error descriptionThe clpasswdremote utility is core dumping due tosegmentationfault.The problem occurs when the user is missing in/etc/passwdin one of the nodes in the cluster.The cspoc.log will log the following:= C_SPOC COMMAND LINE=/usr/es/sb

15、in/cluster/sbin/cl_chpasswd -cspoc-f -r-cspoc -grg1 test3hacmp13: success:/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.origtest3hacmp14: FAILED: evalclpasswdremote -u test3 -praCYOSMwhoJU. -f 2 -l 0hacmp14: cexec54: 3735594 Memoryfault(coredump)hacmp14: RETURN_CODE=139hacmp14: cl_rsh had exit co

16、de =139, see cspoc.logand/or clcomd.log for more informationThe error report will log a CORE DUMP error with thefollowing stack trace:main 94main 88_start 6CThe following symptom code is logged as well:PIDS/5765E6200 LVLS/520 PCSS/SPI2 FLDS/clpasswdr SIG/11FLDS/mainVALU/94 FLDS/_startLocal fixEnsure

17、 that the user exists in /etc/passwd file in all ofthe nodes in the cluster.Problem summaryIf a user is not created using cspoc so that it exists onall nodes in the cluster, then if you try to change thatusers password cluster wide using cspoc, clpasswordremotewill core dump on nodes where the user

18、is not configured.The smit output will look like:Changing password for tstuserhack2: cexec 54 : 8781858 Memory fault(coredump)Problem conclusionA check was added to clpasswdremote to avoid attempting tochange the password on a node where the user is not defined.案例6：V7000緊急的狀態(tài)，緊急的處理使用PowerVC,部署AIX分區(qū)，

19、結(jié)果無(wú)法部署，報(bào)了一堆莫名其妙的錯(cuò)誤。怪了前幾天還能正常部署.今天就不能了檢查PowerVC服務(wù)都正常.登錄HMC看看有沒(méi)有建立分區(qū)profile，發(fā)現(xiàn)沒(méi)有.無(wú)功而返，返回PowerVC繼續(xù)排查，到了存儲(chǔ)器發(fā)現(xiàn)了端倪，不過(guò)看樣子挺嚇人。V7000存儲(chǔ)卷運(yùn)行狀況變成了緊急。登錄V7000查看，發(fā)現(xiàn)V7000沒(méi)有問(wèn)題。那就怪了。其實(shí)PowerVC里的關(guān)于V7000的狀態(tài) 緊急不能反映V7000真正的狀態(tài)，而是通信出現(xiàn)了導(dǎo)致。至于通信出現(xiàn)問(wèn)題，事后問(wèn)網(wǎng)絡(luò)的人，我部署的期間，網(wǎng)絡(luò)正在變更，導(dǎo)致PowerVC不能下發(fā)命令給V7000，PowerVC就把V7000標(biāo)記成緊急了。案例7：一次先入為主的異常故

20、障處理！一臺(tái)P740服務(wù)器通過(guò)SAN交換機(jī)鏈接一臺(tái)DS4700存儲(chǔ)，在硬件維保商更換一次存儲(chǔ)電池（A控）后，業(yè)務(wù)中斷了。我司負(fù)責(zé)數(shù)據(jù)庫(kù)以及系統(tǒng)維護(hù)，被客戶(hù)CALL到現(xiàn)場(chǎng)檢查問(wèn)題，在一番查看后發(fā)現(xiàn)A控上面所有LUN都找不到了，問(wèn)題找到后開(kāi)始排查問(wèn)題。詢(xún)問(wèn)硬件維保商在更換電池時(shí)有沒(méi)有動(dòng)到其他東西，得到了很準(zhǔn)確的回答，我們就換個(gè)電池其他啥也沒(méi)用動(dòng)。于是連接存儲(chǔ)SM把A控所有LUN切到B控，系統(tǒng)內(nèi)能看到所有盤(pán)，OK 問(wèn)題在A控上面，SM中看到的存儲(chǔ)無(wú)報(bào)錯(cuò)無(wú)問(wèn)題，繼續(xù)把原來(lái)A控的LUN切到A控中，系統(tǒng)又找不到了開(kāi)始刪除所有硬盤(pán)然后重新識(shí)別還是不行忙來(lái)忙去 兩三個(gè)小時(shí)過(guò)去了，客戶(hù)在旁邊一直說(shuō)啥時(shí)候能搞好啊

21、，硬件維保商的人沒(méi)事似的在旁邊坐著我要去機(jī)房看一下，必須看一下?？蛻?hù)帶著我們下了機(jī)房，然后看了主機(jī)以及HBA卡連接線，一切看起來(lái)都那么美好。然后看到了存儲(chǔ)A控出的那條光纖線你媽的插錯(cuò)了！ 客戶(hù)用異樣的眼光看著硬件維保商處理問(wèn)題切勿先入為主，任何事要自己確定一下以免有誤！案例8：varyonvg報(bào)錯(cuò)(LVM相關(guān))的分析及處理AIX操作系統(tǒng)在做計(jì)劃內(nèi)升級(jí)操作系統(tǒng)版本變更時(shí)，發(fā)現(xiàn)對(duì)于VG的varyon和varyoff命令有告警信息，經(jīng)分析這只是一個(gè)告警信息，不影響使用，具體告警信息如下：系統(tǒng)環(huán)境：AIX 5.3 TL12 SP7首先，分析當(dāng)時(shí)的報(bào)錯(cuò)內(nèi)容，從操作內(nèi)容來(lái)看，可以看到在執(zhí)行varyoffv

22、g命令時(shí)底層調(diào)用lqueryvg子命令時(shí)報(bào)錯(cuò)，而lqueryvg是一個(gè)查詢(xún)類(lèi)的命令，從這個(gè)命令的返回內(nèi)容說(shuō)明VG的定義信息與VGDA描述不一致。對(duì)于這類(lèi)型的告警信息，重啟操作系統(tǒng)時(shí)便會(huì)自動(dòng)更新VG的相關(guān)信息進(jìn)行自動(dòng)修正。而當(dāng)時(shí)計(jì)劃內(nèi)的變更是升級(jí)操作系統(tǒng)并修改磁盤(pán)的reserve_policy屬性，因此打完補(bǔ)丁后直接重啟操作，在這個(gè)過(guò)程中已經(jīng)把VG信息進(jìn)行了更新。然后，分析當(dāng)時(shí)的操作步驟及LVM的日志進(jìn)行驗(yàn)證對(duì)應(yīng)。當(dāng)時(shí)的操作記錄如下，從操作日志來(lái)看，在重啟操作系統(tǒng)前執(zhí)行過(guò)兩次varyoffvg和一次varyonvg的操作：分析當(dāng)時(shí)的LVM的日志，可以看到第一次varyoffvg時(shí)出現(xiàn)讀取VG信息不一致的報(bào)錯(cuò)。在第一次varyonvg時(shí)出現(xiàn)現(xiàn)樣的信息。在第二次varyoffvg時(shí)也現(xiàn)現(xiàn)同樣的信息。上面信息是操作系統(tǒng)重啟前的信息，下面分析操作系統(tǒng)重啟后LVM相關(guān)的信息，從日志中來(lái)看，當(dāng)操作系統(tǒng)重啟后，VG在varyon時(shí)返回值為0，說(shuō)明重啟過(guò)程已經(jīng)更新了VG的信息。綜上所述，在重啟操作系統(tǒng)后已經(jīng)自動(dòng)更新