Bő fél éve blogoltam a IV07564-es bogárkáról, ami hajlamos a WAS6.0 adminok életét megkeseríteni. Azóta ugye jó sok idő eltelt, így az ember azt hinné, hogy ezt az issue-t is le lehet zárni. Főként mert a bug az AIX 5.3 TL12 SP05ben már elvileg javítva van.
Mint ahogy a hivatalos doksik is írják (IV07564, Java application hang after applying AIX maintenance) a hiba csak a 5.3.12.1-es szinten lévő bos.rte.libpthreads-et érinti, és mivel az 5.3 TL12 SP05-ben már a 5.3.12.2-es van, így lelki nyugalommal mondhatjuk, hogy igen, ez a hiba már tényleg nem fenyegeti a WAS6 rendszereket futtatók életét..
A valóság sajnos az, hogy holott minden a fentiek mellett szól, a gyakorlat még is csak a makacs tényeket részesíti előnyben. Hogy megértsük hol vált külön az elmélet a gyakorlattól, nézzük át kicsit ennek a bugnak az életét (illetve azt is ami nem egészen van dokumentálva). Mázlira a file nevek meglehetősen beszédesek:
IV07564s03 - IV07564s03.111005.epkg.Z
Ez alapján ez a file még 2011.10.05.-én kijött (Anno még én is ezt a verziót töltöttem le). A fixbe belekukkantva az alábbi Abstract-ot találjuk az ecfile-ban: "Ifix for apar IV07564 at 53X SP04."
IV07564s04 - IV07564s04.111005.epkg.Z
Hibajavítás az előző verzióra. A filenév alapján ugyan azon a napon kreálták. A fix-be belenézve az Abstract is azonos (fix for apar IV07564 at 53X SP04.)
IV07564s05 - IV07564s05.111107.epkg.Z
Na innen indul a buli. Az ecfile-ban itt már a "Ifix for apar IV07564 at 53X SP05." leírást olvashatjuk, ami azt jelenti, hogy ez a fix már az SP5-re lett kihozva. A filenév alapján ezt a fix-et 2011.11.07.-én készítették
A probléma ott kezdődik, hogy a hivatalos doksik - amik erre a bugra mutatnak - nem követték a folt fejlesztéseinek változásait:
Java application hang after applying AIX maintenance - Modified date: 2011-10-27
IV07564: HANG IN _EVENT_NOTIFY(). - Modified date: 2011-12-09
- Az elsőnél egyértelműen látszódik, hogy a doksi leragadt a IV07564s03/IV07564s04(?)-es fixnél, így aki az alapján próbál információt szerezni alapból megszívta.
- A másodiknál látszik, hogy valaki Dec 09.-én módosított valamit, de ha megnézzük a letöltési helyre mutató linket (ftp://public.dhe.ibm.com/aix/efixes/iv07564/) nyomban láthatjuk, hogy a file feltöltési dátuma azonos, így gondolom csak egy új lokációt adtak meg a file számára, de elfelejtették a doksi többi részét frissíteni
A vicc az, hogy az ember a turpisságra csak akkor jön rá, ha ténylegesen bele is néz a fixbe és az ecfile-t végigbogozva rájön, hogy ...
- A doksik nem up-to-date-ek
- Az 5.3 TL12 SP5 is érintett a problémában
- A 6.0-ás WAS rendszerek lehet pont ezért hullanak mint a legyek 5.3 alatt (Azt azért hozzá kell persze tenni, hogy a 6.0-ás WAS Supportja 2010 Szeptember 30.-án lejárt így ne csodálkozzanak azok akik outdated SW esetén inkompatibilitást tapasztalnak )
- Ezt lehet le kéne blogolni, hogy más ne szívjon vele annyit :)
For the record - Az eredeti blogbejegyzésemben szóltam, hogy AIX 6.1 is érintett - ott ezeket az APARokat tessék keresni
AIX 6.1 TL07 - IV09681
AIX 6.1 TL06 - IV08153
AIX 6.1 TL05 - IV07839
# Megjegyzem, hogy a 6.1-es AIX-hez kiadott javításokat nem tudtam átnézni, így a hiba ott is fenn álhat (bár az announcement-ek modification date-je azért ad némi bizalomra okot)
2012. április 8., vasárnap
2012. március 3., szombat
Élménybeszámoló - Molylepke vadászat.
Noh. Eljött ez a nap is.. Végre ez a bug vadászat is lezárult, és hivatalos ticket is nyílt róla, így most már írhatok kicsit a részletekről..
A történet ott kezdődött amikor is az egyik HACMP clusterünk failover közben mondhatni "totál beakadt" -> A Resource group-ban (RG) definiált összes resource-t leadta a primary node, a secondary is elkezdte szépen átvenni, illetve az RG is szépen átment, de a folyamat során egy nem várt esemény is előjött: A primary node ez után teljesen elérhetetlen lett. Nézzük hirtelen mit is próbál az ember amikor ilyennel találkozik:
- Nyissunk újabb SSH kapcsolatot a gépre, hátha az előző megszakadt - No response...
- Oks.. elérhető a gép? Nézzünk rá egy ping tesztet - no ping reply.. (előtte volt)
- Jó.. Nézzünk be HMC-re. Az LPAR állapota "running". Tehát elvileg az LPAR megy.. De akkor meg mi a fene?
- Hátha csak a hálózat nyekkent meg. Menjünk be soros terminálról (vterm) - Semmi nem történik.
Ilyenkor ül ki az ember a kertbe, és elkezdi nagy, kikerekedett szemmel nézni a wattafákat, és azon filózni, hogy mikor szüretelheti le majd a fáról a vattát..
Összefoglalva: Az OS se előre, se hátra, az LPAR fut.. Nincs mit tenni.. Indítsuk újra a teljes LPAR-t.
Gép újraindul, log túrás.. Semmi, ami alapján el lehetne indulni.. Jó.. Akkor nézzük meg, hogy egyáltalán tudom e reprodukálni az esetet..
RG visszarak a primary node-ra (szépen visszamegy), majd újabb failover a primary-ról a secondary-re.. Ugyan az.. De legalább tudom, hogy reprodukálható az issue, ami azért sokkal jobb, mintha valami szellemet kéne kergetnem. Mázlimra a gépen szabadon lehetett egy ideig garázdálkodni, így kedvem szerint tesztelgethettem.
Kezdés képen szerettem volna kideríteni, hogy az RG-ben lévő applikációk okozzák e a problémát, vagy mélyebben kell keresgélni. Így fogtam magam, és a HACMP-ben definiált start/stop scripteket ideiglenesen kisöpörtem a színről (így csak a diszkek, LV-k, FS-ek, mount pointok, meg a service IP maradt) és megnéztem így is összeszakad e a gép.. Hát össze..
Jó, akkor nézzük tovább.. Következő ötletem az volt, hogy akkor ráengedek egy trace-t a gépre, úgy futtatok egy ilyen lecsupaszított failover-t, és akkor hátha észreveszem, hogy hol akad meg.. Sajna ez se nyert, mert amint a gép összerogyott a memóriában lévő trace bejegyzések se kerültek kiírásra, így a trace-em teljesen hiányos volt, és csak a standard folyamatok voltak benne, amit amúgy is vár az ember.
1-2 felesleges kísérlet után eljutottam addig, hogy mivel a hálózatom egy idő után úgy is elmegy, így azon keresztül felesleges bármit nézzek, mert simán előfordulhat, hogy a hálózat megszűnése után még a gép csinál valamit a háttérben. Tehát bejelentkeztem virtuális terminálon keresztül (mondván, hogy ami ott van azt csak látnom kell), és úgy elkezdtem monitorozni, hogy a gép meddig jut.. Furcsa mód a HA (illetve az OS) az alábbi parancs után dőlt le:
ifconfig en2 delete ${HACMP_MANAGED_SERVICE_IP_ADDRESS}
Kicsit furcsálltam a dolgot, de gondoltam üsse kutya, mit veszíthetek, ha ezt a lehetőséget is megnézem. Gép újraindul, HA RG ismét a helyére, majd csodálkozva konstatáltam, hogy a fenti parancs futtatásával a gép tényleg ugyan úgy bedől, annak rendje és módja szerint..
Ez egy részről jót jelentett, mert innentől tudtam, hogy a HACMP-nek köze nincs az issue-hoz, más részről viszont bajban voltam, mert az ifconfig-nak ilyet elméletileg még véletlenül se kéne okoznia (az tuti, hogy ezt semmiféle dokumentációban nem említik :))
Ez volt az a pont amikor ez már software call-ért kiáltott.. Tehát hivatalosan is jelentettem a hibát az IBM-es fejlesztők felé, hogy akkor kérem ennek tessék utánanézni. A kezdeti adminisztrációs útvesztőkön, és issue leírás+hiba bizonyítás után aztán a hivatalos IBM supportal eljutottunk addig, hogy itt valami tényleg nem kóser. Első körben ők már egy full system dump-ot kértek tőlem -az után, hogy a gép összecsuklott- hogy megnézzék, hogy a memóriában mi van. Azt analizálva aztán kijött, hogy az összes LPAR-hoz assignolt processzor szál LOCK állapotban van, tehát nem mozdul senki semerre..
Ez persze megmagyarázza, hogy a gép ez után miért nem csinált semmit, de azt nem, hogy hogy jutott el eddig az állapotig. A következő lépésként a fejlesztők küldtek nekem egy kissé átberhelt kernelt, amiben az elérhető összes debug opciót bekapcsolták, hogy aztán az a memóriában (és így a dumpban) is könnyebben követhető legyen.
Az új kernelt életbe léptetve (majd a gépet ismételten megakasztva) immár látható volt, hogy routing lock ált be, tehát kernel szinten volt valami megkergülve. Ez már elég volt a fejlesztőknek, hogy megfelelően e tudják szűkíteni a lehetséges problémák forrását, és ki tudják ténylegesen debugolni, hogy honnan is ered a hiba.
Rövidesen meg is született az eredmény - "A" patch. Megkaptam, telepítettem, és csodák csodájára működött.. Öröm és bóduttá.. Na jó.. Nem teljesen.. Volt még 1-2 dolog amit meg kellett oldani.
-> A patch csak AIX 5.3 TL12 SP04 alá készült el. Sajna a latest SP 05ön állt, és ezen a rendszeren is hamarosan telepíteni kellett, ám mint kiderült az SP05 is érintett volt az issue kapcsán. Sőt mi több, a 6.1es AIX is (TL07,SP2 a latest). Így arra kértem a fejlesztőket, hogy a hivatalos úton olvasszák be ezt a patch-et az érintett AIX verziókba, hogy aztán a következő TL/SP-kben már benne is lehessen.
Így született aztán meg a IV16037-es patch (IBM ID szükséges a megtekintéséhez)
Ha ne adj isten valaki más is hasonló problémákba ütközik a közeljövőben (amíg a fix nem lesz elérhető hivatalosan), akkor némi kis segítség a gyors probléma megoldáshoz:
- teljes system dump force-olása a HMC-ről restartal egybekötve
- Dump analízis kdb-vel. A stack nálam így nézett ki:
- Ők persze ugyan úgy el fogják kérni a dump-ot, hogy megbizonyosodjanak róla, hogy a 2 eset valóban 1 tőről származik e. Ha úgy találják, hogy igen, akkor elérhetővé teszik számodra a patch-et.
A történet ott kezdődött amikor is az egyik HACMP clusterünk failover közben mondhatni "totál beakadt" -> A Resource group-ban (RG) definiált összes resource-t leadta a primary node, a secondary is elkezdte szépen átvenni, illetve az RG is szépen átment, de a folyamat során egy nem várt esemény is előjött: A primary node ez után teljesen elérhetetlen lett. Nézzük hirtelen mit is próbál az ember amikor ilyennel találkozik:
- Nyissunk újabb SSH kapcsolatot a gépre, hátha az előző megszakadt - No response...
- Oks.. elérhető a gép? Nézzünk rá egy ping tesztet - no ping reply.. (előtte volt)
- Jó.. Nézzünk be HMC-re. Az LPAR állapota "running". Tehát elvileg az LPAR megy.. De akkor meg mi a fene?
- Hátha csak a hálózat nyekkent meg. Menjünk be soros terminálról (vterm) - Semmi nem történik.
Ilyenkor ül ki az ember a kertbe, és elkezdi nagy, kikerekedett szemmel nézni a wattafákat, és azon filózni, hogy mikor szüretelheti le majd a fáról a vattát..
Összefoglalva: Az OS se előre, se hátra, az LPAR fut.. Nincs mit tenni.. Indítsuk újra a teljes LPAR-t.
Gép újraindul, log túrás.. Semmi, ami alapján el lehetne indulni.. Jó.. Akkor nézzük meg, hogy egyáltalán tudom e reprodukálni az esetet..
RG visszarak a primary node-ra (szépen visszamegy), majd újabb failover a primary-ról a secondary-re.. Ugyan az.. De legalább tudom, hogy reprodukálható az issue, ami azért sokkal jobb, mintha valami szellemet kéne kergetnem. Mázlimra a gépen szabadon lehetett egy ideig garázdálkodni, így kedvem szerint tesztelgethettem.
Kezdés képen szerettem volna kideríteni, hogy az RG-ben lévő applikációk okozzák e a problémát, vagy mélyebben kell keresgélni. Így fogtam magam, és a HACMP-ben definiált start/stop scripteket ideiglenesen kisöpörtem a színről (így csak a diszkek, LV-k, FS-ek, mount pointok, meg a service IP maradt) és megnéztem így is összeszakad e a gép.. Hát össze..
Jó, akkor nézzük tovább.. Következő ötletem az volt, hogy akkor ráengedek egy trace-t a gépre, úgy futtatok egy ilyen lecsupaszított failover-t, és akkor hátha észreveszem, hogy hol akad meg.. Sajna ez se nyert, mert amint a gép összerogyott a memóriában lévő trace bejegyzések se kerültek kiírásra, így a trace-em teljesen hiányos volt, és csak a standard folyamatok voltak benne, amit amúgy is vár az ember.
1-2 felesleges kísérlet után eljutottam addig, hogy mivel a hálózatom egy idő után úgy is elmegy, így azon keresztül felesleges bármit nézzek, mert simán előfordulhat, hogy a hálózat megszűnése után még a gép csinál valamit a háttérben. Tehát bejelentkeztem virtuális terminálon keresztül (mondván, hogy ami ott van azt csak látnom kell), és úgy elkezdtem monitorozni, hogy a gép meddig jut.. Furcsa mód a HA (illetve az OS) az alábbi parancs után dőlt le:
ifconfig en2 delete ${HACMP_MANAGED_SERVICE_IP_ADDRESS}
Kicsit furcsálltam a dolgot, de gondoltam üsse kutya, mit veszíthetek, ha ezt a lehetőséget is megnézem. Gép újraindul, HA RG ismét a helyére, majd csodálkozva konstatáltam, hogy a fenti parancs futtatásával a gép tényleg ugyan úgy bedől, annak rendje és módja szerint..
Ez egy részről jót jelentett, mert innentől tudtam, hogy a HACMP-nek köze nincs az issue-hoz, más részről viszont bajban voltam, mert az ifconfig-nak ilyet elméletileg még véletlenül se kéne okoznia (az tuti, hogy ezt semmiféle dokumentációban nem említik :))
Ez volt az a pont amikor ez már software call-ért kiáltott.. Tehát hivatalosan is jelentettem a hibát az IBM-es fejlesztők felé, hogy akkor kérem ennek tessék utánanézni. A kezdeti adminisztrációs útvesztőkön, és issue leírás+hiba bizonyítás után aztán a hivatalos IBM supportal eljutottunk addig, hogy itt valami tényleg nem kóser. Első körben ők már egy full system dump-ot kértek tőlem -az után, hogy a gép összecsuklott- hogy megnézzék, hogy a memóriában mi van. Azt analizálva aztán kijött, hogy az összes LPAR-hoz assignolt processzor szál LOCK állapotban van, tehát nem mozdul senki semerre..
Ez persze megmagyarázza, hogy a gép ez után miért nem csinált semmit, de azt nem, hogy hogy jutott el eddig az állapotig. A következő lépésként a fejlesztők küldtek nekem egy kissé átberhelt kernelt, amiben az elérhető összes debug opciót bekapcsolták, hogy aztán az a memóriában (és így a dumpban) is könnyebben követhető legyen.
Az új kernelt életbe léptetve (majd a gépet ismételten megakasztva) immár látható volt, hogy routing lock ált be, tehát kernel szinten volt valami megkergülve. Ez már elég volt a fejlesztőknek, hogy megfelelően e tudják szűkíteni a lehetséges problémák forrását, és ki tudják ténylegesen debugolni, hogy honnan is ered a hiba.
Rövidesen meg is született az eredmény - "A" patch. Megkaptam, telepítettem, és csodák csodájára működött.. Öröm és bóduttá.. Na jó.. Nem teljesen.. Volt még 1-2 dolog amit meg kellett oldani.
-> A patch csak AIX 5.3 TL12 SP04 alá készült el. Sajna a latest SP 05ön állt, és ezen a rendszeren is hamarosan telepíteni kellett, ám mint kiderült az SP05 is érintett volt az issue kapcsán. Sőt mi több, a 6.1es AIX is (TL07,SP2 a latest). Így arra kértem a fejlesztőket, hogy a hivatalos úton olvasszák be ezt a patch-et az érintett AIX verziókba, hogy aztán a következő TL/SP-kben már benne is lehessen.
Így született aztán meg a IV16037-es patch (IBM ID szükséges a megtekintéséhez)
Ha ne adj isten valaki más is hasonló problémákba ütközik a közeljövőben (amíg a fix nem lesz elérhető hivatalosan), akkor némi kis segítség a gyors probléma megoldáshoz:
- teljes system dump force-olása a HMC-ről restartal egybekötve
- Dump analízis kdb-vel. A stack nálam így nézett ki:
- Ha ilyesmi, vagy a ticketben leírthoz hasonló stack-el találkozol, nyiss egy SW call-t az IBM felé, és hivatkozz a fenti fix-re.pvthread+031300 STACK: [0000932C].unlock_enable_mem+000020 () [00204F50]rt_setgate+0001F8 (??, ??, ??) [043D6A08]in_ifscrub+000488 (??, ??) [043D8050]in_control+0009A8 (??, ??, ??, ??) [04436B38]udp_usrreq+000214 (??, ??, ??, ??, ??) [0020E7F4]ifioctl+00075C (??, ??, ??) [0025FDFC]soo_ioctl+000494 (??, ??, ??) [004A8968]common_ioctl+0000C0 (??, ??, ??, ??) [00003810].svc_instr+000110 () [kdb_get_memory] no real storage @ 2FF22390 [D03B1D14]D03B1D14 ()
- Ők persze ugyan úgy el fogják kérni a dump-ot, hogy megbizonyosodjanak róla, hogy a 2 eset valóban 1 tőről származik e. Ha úgy találják, hogy igen, akkor elérhetővé teszik számodra a patch-et.
2012. február 14., kedd
fuser - némileg másként
A múltkor blogbejegyzés után kedvet kaptam némi kis turkászásban a kernel térben, úgy hogy íme egy újabb szösszenet arról, hogy a rendszernek mit is kell csinálnia amikor mi csak úgy dobálózunk a parancsokkal :)
Na szóval.. A mostani alkalomra a fuser nevű parancsot néztem ki magamnak.. Sokat nem kell róla mondani: Általános ismérve, hogy ha egy FS nyitva van, akkor ezt szoktuk meghívni, hogy megnézzük mi is fogja. Nézzük, hogy ezt a funkciót a kernel térből hogy is lehetne elérni:
Első körben kell nekünk egy mount point.. Az én esetemben ez a /opt/IBM lesz, mert miért ne :)
Első körben a kontroll teszt: Nézzük, hogy a rendszer mit is tud róla:
- Meg kell keresni az adott mount point memória pointerjét
- Ezt a pointert használva megnézni az elérhető I-node bejegyzések pointereit, majd leválogatni amire van bármiféle hivatkozás
- A leválogatott hivatkozásokat alapul véve meg kell nézni, hogy melyiknek mi a Gnode (generic node structure) szegmense
- Ezen segmensekből már le tudjuk válogatni, hogy melyiknek milyen thread a szülője, amiből meg direkt megtalálhatjuk a thread-hez rendelt PID-et.
A valóságban:
Első körben ugye a mount-hoz tartozó cím kell. Annyi probléma van, hogy a mount-ot kikérve ilyen összevisszaságot kapunk:
- Komolyan végig kell mindent böngésszek, úgy hogy közben kifolyik a szemem?
- Miért nem lehet ezt 1 sorban kirakni, hogy legalább greppelni lehessen rá?
Persze azért annyira mégse rossz a helyzet, csak kicsit bűvészkedni kell az awk-al, és nyomban meglesz az ami nekünk kell:
Ugye hogy így szebb.. Na szóval megvan a pointerünk (F100010020684550). Akkor kérjük le milyen i-node bejegyzések vannak alatta:
- Az első és második oszlop lényegében ugyan azt takarja. Az első az index-szám, a második pedig a VFS_VNODE pointer.
- A 3. szám egy úgy nevezett counter. Ez mutatja, hogy hány kernel thread használja éppen az adott VFS_VNODE-ot.
- A 4. lesz a VFS_VNODE-hoz tartozó GNODE.
- Az 5.-et most bocs de kihagyom, mert érdektelen jelen szempontból
Ami nekünk ezek közül kell, az azok a GNODE regiszterek, amelyeknek COUNT-ja nagyobb mint 0. Ezt kb az alábbi scriptelési módszerrel tudjuk előhozni:
Egy baj van - Ez a lista helyenként iszonyat nagy.. Itt se épp rövid.. A problémám meg az, hogy az itt található GNODE ID-kat kéne mind végigjárjam az alábbi módon:
1130574, 1253494. Amiket fentebb is láttunk.. Sőt, még azt is tudjuk, hogy egy sh, meg egy java processről van szó :)
Ha ne adj isten lusták vagyunk visszamenni a fenti script után a kdb-be, akkor némi kis módosítással nyomban ki is lehet kérni az ID-ket:
# Mint fent említettem: A módszer csak azokra a GNODE-okra működik aminek a countere (aktív thread-je) nagyobb mint 0. Ez azért problémás, mert ha egy process használ egy file-t, de az épp nem aktív (írás nélküli file, pl tail esetén), akkor ez a módszer is hibádzik. További probléma, hogy a submount-okat (amik szintén fogják az FS-t umount esetén) szintén nem képes kijelezni, szóval nyugodtan tekintsétek ezt is amolyan érdekességnek, tekintve, hogy mind a fuser, mind az lsof bőven alkalmasabb ezeknek a megkeresésére (általában - volt amikor ez a módszer talált meg nekem egy olyan thread-et, amiről más program sose hallott)
Na szóval.. A mostani alkalomra a fuser nevű parancsot néztem ki magamnak.. Sokat nem kell róla mondani: Általános ismérve, hogy ha egy FS nyitva van, akkor ezt szoktuk meghívni, hogy megnézzük mi is fogja. Nézzük, hogy ezt a funkciót a kernel térből hogy is lehetne elérni:
Első körben kell nekünk egy mount point.. Az én esetemben ez a /opt/IBM lesz, mert miért ne :)
Első körben a kontroll teszt: Nézzük, hogy a rendszer mit is tud róla:
Szupi.. Na akkor nézzük ugyan ezt a kernel térben. A módszer az alábbi dióhéjban:test_server@root:/ # fuser -cux /opt/IBM /opt/IBM: 1130574c(root) 1253494c(root)
- Meg kell keresni az adott mount point memória pointerjét
- Ezt a pointert használva megnézni az elérhető I-node bejegyzések pointereit, majd leválogatni amire van bármiféle hivatkozás
- A leválogatott hivatkozásokat alapul véve meg kell nézni, hogy melyiknek mi a Gnode (generic node structure) szegmense
- Ezen segmensekből már le tudjuk válogatni, hogy melyiknek milyen thread a szülője, amiből meg direkt megtalálhatjuk a thread-hez rendelt PID-et.
A valóságban:
Első körben ugye a mount-hoz tartozó cím kell. Annyi probléma van, hogy a mount-ot kikérve ilyen összevisszaságot kapunk:
(0)> mount
GFS DATA TYPE FLAGS
1 F10001001D6868B0 014D4D60 F1000100206D2080 JFS2 DEVMOUNT
... /dev/hd4 mounted over /
2 F10001001D686950 014D4D60 F1000100206A4480 JFS2 DEVMOUNT
... /dev/hd2 mounted over /usr
3 F10001001D6869F0 014D4D60 F1000100206FB080 JFS2 DEVMOUNT
... /dev/hd9var mounted over /var
4 F10001001D686810 014D4D60 F1000100206FC880 JFS2 DEVMOUNT
... /dev/hd3 mounted over /tmp- Komolyan végig kell mindent böngésszek, úgy hogy közben kifolyik a szemem?
- Miért nem lehet ezt 1 sorban kirakni, hogy legalább greppelni lehessen rá?
Persze azért annyira mégse rossz a helyzet, csak kicsit bűvészkedni kell az awk-al, és nyomban meglesz az ami nekünk kell:
(0)> mount |awk '{a[NR]=$0} /\/opt\/IBM$/ {print a[NR],a[NR-1]}'
... /dev/IBMlv mounted over /opt/IBM 14 F100010020684550 014D4D60 F1000100226C2C80 JFS2 DEVMOUNTUgye hogy így szebb.. Na szóval megvan a pointerünk (F100010020684550). Akkor kérjük le milyen i-node bejegyzések vannak alatta:
Na itt egy újabb probléma.. Mi ez a sok szám, és mit jelentenek? Nos A válasz a következő:(0)> mount F100010020684550 |grep -E "DIR|REG|SOCK" |tail -5 648 F1000100241643E8 0 F1000100241640B0 F100010020684550 DIR 649 F1000100240E03E8 0 F1000100240E00B0 F100010020684550 DIR 650 F100010024092FE8 1 F100010024092CB0 F100010020684550 REG 651 F10001002411B7E8 2 F10001002411B4B0 F100010020684550 DIR 652 F1000100226D2FE8 1 F1000100226D2CB0 F100010020684550 DIR ROOT
- Az első és második oszlop lényegében ugyan azt takarja. Az első az index-szám, a második pedig a VFS_VNODE pointer.
- A 3. szám egy úgy nevezett counter. Ez mutatja, hogy hány kernel thread használja éppen az adott VFS_VNODE-ot.
- A 4. lesz a VFS_VNODE-hoz tartozó GNODE.
- Az 5.-et most bocs de kihagyom, mert érdektelen jelen szempontból
Ami nekünk ezek közül kell, az azok a GNODE regiszterek, amelyeknek COUNT-ja nagyobb mint 0. Ezt kb az alábbi scriptelési módszerrel tudjuk előhozni:
(0)> mount F100010020684550|grep -E "DIR|REG|SOCK" |awk ' { if ($3 != "0") print }'
154 F100010036F6A3E8 1 F100010036F6A0B0 F100010020684550 REG
157 F100010036F3A3E8 1 F100010036F3A0B0 F100010020684550 REG
160 F100010036F99FE8 1 F100010036F99CB0 F100010020684550 REG
163 F100010036F69FE8 1 F100010036F69CB0 F100010020684550 REG
266 F100010036FA6FE8 1 F100010036FA6CB0 F100010020684550 REG
556 F1000100244D2FE8 1 F1000100244D2CB0 F100010020684550 REG
557 F1000100243B57E8 1 F1000100243B54B0 F100010020684550 REG
558 F1000100244CC3E8 1 F1000100244CC0B0 F100010020684550 REG
559 F1000100244EBBE8 1 F1000100244EB8B0 F100010020684550 REG
560 F1000100243B0BE8 1 F1000100243B08B0 F100010020684550 REG
561 F1000100244CB7E8 1 F1000100244CB4B0 F100010020684550 REG
562 F1000100244A93E8 1 F1000100244A90B0 F100010020684550 REG
563 F1000100244C8BE8 1 F1000100244C88B0 F100010020684550 REG
652 F1000100226D2FE8 1 F1000100226D2CB0 F100010020684550 DIR ROOTEgy baj van - Ez a lista helyenként iszonyat nagy.. Itt se épp rövid.. A problémám meg az, hogy az itt található GNODE ID-kat kéne mind végigjárjam az alábbi módon:
3.-ra csak ráhibáztam az egyikre, de persze ezt így egyesével végigjátszani valami halál.. Mindenesetre ha megvan a pvproc cím, akkor abból már az egyik process-t meg is találhatjuk:(0)> gnode F1000100243B08B0 |grep gn_seg gn_seg........ 00000000000086A6 (0)> scb 2 00000000000086A6 |grep pvproc pvproc pointer (pvproc) : 0000000000000000 (0)> gnode F1000100244C88B0 |grep gn_seg gn_seg........ 00000000000246AD (0)> scb 2 00000000000246AD |grep pvproc pvproc pointer (pvproc) : 0000000000000000 (0)> gnode F100010036F99CB0 |grep gn_seg gn_seg........ 00000000000732D8 (0)> scb 2 00000000000732D8 |grep pvproc pvproc pointer (pvproc) : F100070F00045000
Bingo.. 1130574 az egyik PID amint fentebb is láttunk.. Na de akkor hogy is lehet ezt normálisan végignézni, úgy hogy az összes GNODE ID-t végigjátsszuk? Hát, a szomorú hír, hogy a kdb nem tud belső scriptelést, így a shell-re kell támaszkodjunk, ami meg egy részről iszonyat erőforrás zabáló, más részről meg a sok fork miatt ágyúval verébre módszer is. Annyi segítségünk mondjuk van, hogy a kdbnek van '-script' kapcsolója, ami pont az ilyen munkákat igyekszik megkönnyíteni, de azért ez még mindig kevés az optimális működéshez.(0)> proc F100070F00045000 |grep ^pvproc pvproc+045000 276 java ACTIVE 011404E 0132076 0000000030588400 0 0013 (0)> hcal 011404E Value hexa: 0011404E Value decimal: 1130574
test_server@root:/ # for GN_SEG in $(
> for GNODE_ID in $(echo mount F100010020684550|kdb -script |grep -E "DIR|REG|SOCK" |awk ' { if ($3 != "0") print }')
> do
> echo gnode $GNODE_ID|kdb -script|awk '/gn_seg/ {print $NF}'
> done)
> do
> echo scb 2 $GN_SEG |kdb -script|awk '/pvproc/ {print}'
> done|sort -u|grep -v 0000000000000000
pvproc pointer (pvproc) : F100070F00045000
pvproc pointer (pvproc) : F100070F0004C800(0)> proc F100070F00045000 |grep ^pvproc pvproc+045000 276 java ACTIVE 011404E 0132076 0000000030588400 0 000E (0)> hcal 011404E Value hexa: 0011404E Value decimal: 1130574 (0)> proc F100070F0004C800 |grep ^pvproc pvproc+04C800 306 sh ACTIVE 0132076 0000001 0000000008466400 0 0001 (0)> hcal 0132076 Value hexa: 00132076 Value decimal: 1253494
1130574, 1253494. Amiket fentebb is láttunk.. Sőt, még azt is tudjuk, hogy egy sh, meg egy java processről van szó :)
Ha ne adj isten lusták vagyunk visszamenni a fenti script után a kdb-be, akkor némi kis módosítással nyomban ki is lehet kérni az ID-ket:
test_server@root:/ # MOUNT=$(echo mount |kdb -script|awk '{a[NR]=$0} /\/opt\/IBM$/ {print a[NR-1]}'|awk '{print $2}')
test_server@root:/ # for PVPROC in $(
> for GN_SEG in $(
> for GNODE_ID in $(echo "mount $MOUNT" |kdb -script|grep -E "DIR|REG|SOCK" |awk ' { if ($3 != "0") print $4}')
> do
> echo gnode $GNODE_ID|kdb -script|awk '/gn_seg/ {print $NF}'
> done)
> do
> echo scb 2 $GN_SEG |kdb -script|awk '/pvproc/ {print $NF}'
> done|sort -u|grep -v 0000000000000000)
> do
> echo proc $PVPROC|kdb -script|grep ^pvproc
> done
pvproc+045000 276 java ACTIVE 011404E 0132076 0000000030588400 0 0017
pvproc+04C800 306 sh ACTIVE 0132076 0000001 0000000008466400 0 0001# Mint fent említettem: A módszer csak azokra a GNODE-okra működik aminek a countere (aktív thread-je) nagyobb mint 0. Ez azért problémás, mert ha egy process használ egy file-t, de az épp nem aktív (írás nélküli file, pl tail esetén), akkor ez a módszer is hibádzik. További probléma, hogy a submount-okat (amik szintén fogják az FS-t umount esetén) szintén nem képes kijelezni, szóval nyugodtan tekintsétek ezt is amolyan érdekességnek, tekintve, hogy mind a fuser, mind az lsof bőven alkalmasabb ezeknek a megkeresésére (általában - volt amikor ez a módszer talált meg nekem egy olyan thread-et, amiről más program sose hallott)
Feliratkozás:
Bejegyzések (Atom)