2013. január 29., kedd

Mickey egér, HACMP, meg a többiek..

Némileg úgy érzem most magam, mint ahogy régen a BBC stábja érezhette magát, amikor is 1946ban (állítólag, bár egyesek szerint ez is kacsa) ismét ott folytatták az ominózus Mickey Mouse történetet, ahol anno 1939 Szeptember 1.-jén abbahagyták.

Ok, némileg túlzó a kép, de azért nekem is volt 1-2 komolyabb harcom az elmúlt 1-2 hónapban, munkahely váltás, költözés külföldre, meg ami vele jár.. Szóval nem volt eseménytelen az elmúlt időszak, ami sajna a blog rovására is ment láthatólag.
Na de viszont most megpróbálom azt amit anno a BBC-sek is - folytatni ahol abbamaradt minden, mintha misem történt volna..

Na szóval.. Aktuális problémánk tárgya egy HACMP-s node, ahol a clcomdES daemon fölött elkezdtek körözni a keselyűk, ugyan is ránézésre halottnak nézett ki..
Az AIX kommandó az újraélesztést megkezdte, de a beteg nem reagált a kezelésre:
[server:root:/home/root:] lssrc -s clcomdES
Subsystem         Group            PID          Status 
 clcomdES         clcomdES                      inoperative
[server:root:/home/root:] startsrc -s clcomdES
0513-059 The clcomdES Subsystem has been started. Subsystem PID is 7033284.
[server:root:/home/root:] 
[server:root:/home/root:] lssrc -s clcomdES   
Subsystem         Group            PID          Status 
 clcomdES         clcomdES                      inoperative
Az orvosi lapot átnézve kiderült, hogy betegünk valószínű még is él, csak vagy kómába esett, vagy önmagán kívül van:
[server:root:/:] tail -1 /var/hacmp/clcomd/clcomd.log 
Mon Jan 28 15:03:18 2013: bind (../../../../../../../src/43haes/usr/sbin/cluster/clcomd/clcomd.c:5533): Address already in use
Persze minderről a hatóságok semmit nem tudtak..
[server:root:/var/hacmp/clcomd:] ps -ef |grep clcom 
    root 5480538 7143926   0 15:05:31  pts/1  0:00 grep clcom 
.. csak annyit, hogy a clcomdES által gyakran használt erőforrásokat valami tényleg épp fogja:
# Kis magyarázat: a clcomdES által használt default port a 6191
[server:root:/var/hacmp/clcomd:] netstat -Aan |grep 6191 |grep LISTEN
f10006000243c398 tcp4       0      0  *.6191             *.*                LISTEN
Ilyenkor általában csak odasétál az ember az illetékes besúgóhoz, megkéri hogy mondja már meg ki jár rá a dugi csokira, de szomorúan kell konstatáljuk, hogy halvány lila fogalma nincs:
[server:root:/var/hacmp/clcomd:] rmsock f10006000243c398 tcpcb
getprocdata: malloc failed
Na jó... Ha a szokványos eszközök nem mennek, akkor tényleg muszáj lesz nekünk is bemocskolnunk a kezünk, és megnézni hogy a Disc-réten mi ROMolhatott el..

Kezdjük is a kernellel, ha már a gyanúsítgatásnál tartunk ("Ahol a kormány, ott van a gáz.."). Aki olvasta eddig a blogomat annak ez a fordulat azt hiszem nem lesz komolyabb meglepetés :)
Akinek még is, annak javaslom az itt emlegetett módszerek és parancsok áttanulmányozását a folytatás előtt

Na szóval.. a netstat megsúgta nekünk, hogy a f10006000243c398-es dugi csokira jár rá a kis szellemünk, úgy hogy kezdjünk el az után nyomozni első körben:
[server:root:/var/hacmp/clcomd:] kdb
(0)> ns
Symbolic name translation off
(0)> si f10006000243c398 tcpcb |grep ACTIVE
F100070F01012000 16456*clcomd   ACTIVE 004812E 0031166 00000003184E1400   0 0014

(0)> proc F100070F01012000 |head
              SLOT NAME     STATE      PID    PPID          ADSPACE  CL #THS

F100070F01012000 16456 clcomd   ACTIVE 004812E 0031166 00000003184E1400   0 0014
Hoppá.. Tehát a socketet még is csak egy clcomd fogja, de akkor miért nem vették észre a nyomozó kollégák??
(0)> hcal 004812E
Value hexa: 0004812E          Value decimal: 295214

[server:root:/:] ps -fp 295214
     UID     PID    PPID   C    STIME    TTY  TIME CMD
       -  295214       -   -                     - <exiting>
Ja kérem.. Ez itt egy megrendezett öngyilkossággal egybekötött biztosítási csalás.. Na keressük meg a cinkosokat:
(0)> proc F100070F01012000 |grep THREAD
THREAD..... threadlist :F100070F10807300 
THREAD..... threadcount:00000014  ........... active     :00000002

(0)> th F100070F10807300 |head
                SLOT NAME     STATE    TID PRI   RQ CPUID  CL  WCHAN

F100070F10807300 32883  ZOMB  0731E3 03C    0         0  

NAME................ 
WTYPE............... WZOMB    
.................tid :00000000000731E3  ......tsleep :FFFFFFFFFFFFFFFF
...............flags :00000000  ..............flags2 :00000000
...........pmcontext :00000000
DATA.........pvprocp :F100070F01012000 
Hoppá.. Nekromancia, vagy mifene? Ki mozgatja a szálakat?
(0)> th F100070F10807300 |grep prev 
LINKS.....prevthread :F100070F10008C00 
LINKS.....prevthread :0000000000000000

(0)> th F100070F10008C00 |head
F100070F10008C00  140 clcomd   SLEEP 08C029 03C    4         0  F100070F010121B8 
Jó.. 1 megvan.. Vannak még?
(0)> th -n clcomd
                SLOT NAME     STATE    TID PRI   RQ CPUID  CL  WCHAN

F100070F10007C00  124 clcomd   SLEEP 07C0ED 03C    4         0  F1000110129D9A70 01125380 
F100070F10008C00  140 clcomd   SLEEP 08C029 03C    4         0  F100070F010121B8 
Aham.. szóval 2 fő process, 1-1 threaddel.. Na és ők épp mit csinálnak?
(0)> f F100070F10008C00
pvthread+008C00 STACK:
[0005EEF4]ep_sleep+000128 (0000000000056DA0, A0000000000090B2 [??])
[0014384C]kexitx+000F6C (??)
[0015AAD8]kexit+000080 ()
[kdb_get_virtual_memory] no real storage @ FFFFFFFF3FFFE40

(0)> f F100070F10007C00
pvthread+007C00 STACK:
[002FF8C0]slock+0006A4 (00000000002E0268, 80000000000090B2 [??])
[00009558].simple_lock+000058 ()
[002CB3D0]j2_rename+000188 (??, ??, ??, ??, ??, ??, ??)
[00408C34]vnop_rename+0002B4 (??, ??, ??, ??, ??, ??, ??)
[0046A8F4]rename+00030C (??, ??)
[0486570C]my_rename+0001C4 (0000000020023728, 00000000200C149C)
[00003810].svc_instr+000110 ()
[kdb_get_virtual_memory] no real storage @ 200C0FD8
[10013190]log_printf+0002FC (00000000, 00000000, 00000000, 00000000,
   00000000, 00000000, 00000000, 00000000)
Az egyik épp ki akar lépni, de azért még vár egy kicsit (tapsra talán, meg nem mondom), de a másik már érdekesebb: Ott a jelek szerint épp valami JFS2-es FS alatt volt valami átnevezősdi, ami valahogy még is csak megbicsaklott..
És hiába tűnt ez az elején HACMP hibának, a bizonyítékok alapján ez inkább tűnik AIX issue-nak.. A pénz csak pénz, a stack az meg csak stack na..
Azok alapján meg az ügy erősen hajaz az alábbi hibák egyikére:
- IZ96928
- IZ40258
Na most ha megnézitek, akkor azért ezek a bűnügyi megelőző kezelések nem épp a legfrissebben szabadult bűnözőkre lettek kitalálva (avagy jó régi patchekről van szó).. Úgy hogy ha már itt tartunk nézzük már meg, hogy ezt a drágát melyik korból szalajthatták?
[server:root:/:] oslevel -s
5300-08-08-0943
Jah.. Jó.. Ez a TL/SP még anno 2009 Novemberében lett kiadva.. Az se ma volt.. Had ne mondjam azóta mennyi fix kijött, jah meg az 5.3as AIX hivatalos supportja is lejárt 2012 Áprilisában.
Na szóval itt rendesen el vannak egyesek maradva.. És hiába kérdezik meg az SWG-sek (software group) hogy tuti minden patch fent van e, attól még a hülye AIX admin csak abból főzhet amit a konyhában talál (amíg ki nem derül, hogy a Műanyag tálba lévő melegítendő kaját lehet még sem a sütőn kellett volna megpróbálni felmelegíteni).

Tanulság: Ha tetszik, ha nem tessék már azokat a rohadt rendszereket frissíteni (és nem csak a security miatt)

2012. november 4., vasárnap

HACMP failover issue - Unable to unmount the filesystem

Az ember egy idő után már hajlamos azt hiszi, hogy azért nem lehet könnyen meglepni, ha már egy csomó szívást átélt, meg már a kdb-s bugyrokat is megjárta.. Hiába tudjuk, hogy Murphy csak az ilyen jelekre vár, mindig azt hisszük, hogy fel tudjuk venni vele a kesztyűt.. Aztán az ember szembe kap egy általánosnak tűnő problémát, elkezdi a saját kis módján investigálni, majd akkor koppan amikor rájön, hogy valami mégse úgy megy ahogy kéne, vagy valami még így is van amire nem gondolt előzőleg.

Ez se volt most másként.. Felhívtak kollégák, hogy lenne egy HACMP failover probléma: Szegény RG nem tud átállni, és meg kéne már nézni, hogy mi a rákért nem..
Hát jó.. hacmp.out túrás , és elég gyorsan szembejön az első gyanús jel:
***************************
Nov 3 2012 19:42:13 !!!!!!!!!! ERROR !!!!!!!!!!
***************************
Nov 3 2012 19:42:13 cl_deactivate_vgs: Failed varyoff of appvg.
Aham.. na jó.. nézzük mi van még itt, ami miatt ez előjöhetett:
+app_rg:cl_deactivate_vgs(5.910):appvg[vgs_varyoff+282] varyoffvg appvg
0516-012 lvaryoffvg: Logical volume must be closed.  If the logical
        volume contains a filesystem, the umount command will close
        the LV device.
0516-942 varyoffvg: Unable to vary off volume group appvg.
Ahh.. haladunk.. Mi törpént az FS-el?
+app_rg:cl_deactivate_fs(.160)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy
+app_rg:cl_deactivate_fs(2.160)[fs_umount+66] : At this point, unmount of /var/mqm/RGmount has not worked. So,
+app_rg:cl_deactivate_fs(2.160)[fs_umount+67] : Send a SIGKILL to all processes having open file
+app_rg:cl_deactivate_fs(2.160)[fs_umount+68] : descriptors within this logical volume to allow
+app_rg:cl_deactivate_fs(2.160)[fs_umount+69] : the umount to succeed.
+app_rg:cl_deactivate_fs(2.160)[fs_umount+71] date '+%h %d %H:%M:%S.000'
Nov 03 19:38:46.000
+app_rg:cl_deactivate_fs(2.160)[fs_umount+72] fuser -k -u -x /dev/RG_LV
/dev/RG_LV:   782460(wasRGuser)  782460(wasRGuser)  868596(wasRGuser)  868596(wasRGuser)  938078(wasRGuser)  938078(wasRGuser) 1081448(wasRGuser) 1081448(wasRGuser)
+app_rg:cl_deactivate_fs(2.740)[fs_umount+73] fuser -c -k -u -x /var/mqm/RGmount
/var/mqm/RGmount:
+app_rg:cl_deactivate_fs(3.260)[fs_umount+74] date '+%h %d %H:%M:%S.000'
Nov 03 19:38:47.000
+app_rg:cl_deactivate_fs(3.260)[fs_umount+77] : Wait 2 seconds for the kills to be effective
+app_rg:cl_deactivate_fs(3.260)[fs_umount+79] sleep 2
+app_rg:cl_deactivate_fs(5.260)[fs_umount+82] : Unmount of /var/mqm/RGmount failed. If the force option can be used, try it here.
+app_rg:cl_deactivate_fs(5.260)[fs_umount+84] [[ -n '' ]]
+app_rg:cl_deactivate_fs(5.260)[fs_umount+99] (( 0 == 57 ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+123] (( 0 == 60 ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+52] ((count++ ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+52] (( count <= 60))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+55] : Try to unmount the file system
+app_rg:cl_deactivate_fs(5.270)[fs_umount+56] date '+%h %d %H:%M:%S.000'
+app_rg:cl_deactivate_fs(5.270)[fs_umount+56] : Attempt 2 of 61 to unmount at Nov 03 19:38:49.000
+app_rg:cl_deactivate_fs(5.270)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy.
Ez a fázis már az application stop után van, ergo a HACMP joggal van felháborodva, hogy miért nem szabad már a device, ha ő azt át akarja adni a másik node-na.. Sebaj, 5.3 óta fel van készítve a HA erre is, gyenge fuser -kux az LV-re megoldja.. fuser -ckux után látszik, hogy tényleg nem maradt process ami használná az FS-t, úgy hogy semmi gáz, mehet az umount..
De álj.. Megint device busy?? Na innen indul a vicces rész.. Főleg amikor az ember eljut a logban eddig:
+app_rg:cl_deactivate_fs(194.630)[fs_umount+56] : Attempt 61 of 61 to unmount at Nov 03 19:41:58.000
+app_rg:cl_deactivate_fs(194.630)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy
+app_rg:cl_deactivate_fs(194.760)[fs_umount+66] : At this point, unmount of /var/mqm/RGmount has not worked. So,
+app_rg:cl_deactivate_fs(194.760)[fs_umount+67] : Send a SIGKILL to all processes having open file
+app_rg:cl_deactivate_fs(194.760)[fs_umount+68] : descriptors within this logical volume to allow
+app_rg:cl_deactivate_fs(194.760)[fs_umount+69] : the umount to succeed.
+app_rg:cl_deactivate_fs(194.760)[fs_umount+71] date '+%h %d %H:%M:%S.000'
Nov 03 19:41:58.000
+app_rg:cl_deactivate_fs(194.770)[fs_umount+72] fuser -k -u -x /dev/RG_LV
/dev/RG_LV:
+app_rg:cl_deactivate_fs(195.300)[fs_umount+73] fuser -c -k -u -x /var/mqm/RGmount
/var/mqm/RGmount:
+app_rg:cl_deactivate_fs(195.810)[fs_umount+74] date '+%h %d %H:%M:%S.000'
Nov 03 19:41:59.000
+app_rg:cl_deactivate_fs(195.810)[fs_umount+77] : Wait 2 seconds for the kills to be effective
+app_rg:cl_deactivate_fs(195.810)[fs_umount+79] sleep 2
+app_rg:cl_deactivate_fs(197.810)[fs_umount+82] : Unmount of /var/mqm/RGmount failed. If the force option can be used, try it here.
+app_rg:cl_deactivate_fs(197.810)[fs_umount+84] [[ -n '' ]]
+app_rg:cl_deactivate_fs(197.810)[fs_umount+99] (( 60 == 57 ))
+app_rg:cl_deactivate_fs(197.810)[fs_umount+123] (( 60 == 60 ))
+app_rg:cl_deactivate_fs(197.810)[fs_umount+126] : Out of retries to unmount /var/mqm/RGmount. Game over, man, game over.
+app_rg:cl_deactivate_fs(197.810)[fs_umount+128] cl_echo 25 'cl_deactivate_fs: Failed umount of /var/mqm/RGmount.\n' cl_deactivate_fs /var/mqm/RGmount
A "Game over, man, game over" kedves kis üzenet a fejlesztőktől, és meg meg is mosolyogtatna ha nem látnám, hogy szegény HA-m 61x próbálta meg lenyomni a szerencsétlen FS-t de mind végig Device busy-t kapott.

OS oldalról elnézve az FS valóban ott van a mount alatt, és ha én akarom leszedni akkor ugyan azt kapom:
server@root:/ # mount |grep RGmount
         /dev/RG_LV     /var/mqm/RGmount   jfs2   Nov 03 19:22 rw,log=INLINE
server@root:/ # fuser -cux /dev/RG_LV
server@root:/ # umount /var/mqm/RGmount
umount: 0506-349 Cannot unmount /dev/RG_LV: The requested resource is busy.
Na akkor áljunk meg itt picit.. Mi az amit érdemes megnézni ilyenkor?
- Használja e valami az FS-t
- Megtettem, nem dobott semmit..
- Haszmálja e az LV-t valami?
- Ez az amit a HACMP is megnézett, és aminek amúgy több értelme is van, mint az FS-t nézni -> van 1-2 olyan parancs ami az LV-ket cseszteti direktben, ergo ha a /dev/LV-re ráengedünk egy fuser-t akkor azokat is meg tudjuk fogni.. A HA 1x ezeket le is gyilkolta, viszont utána már nem talált semmit
- Nincs e submount az adott FS alatt
- Amennyiben egy másik FS van a lemountolandó alá felhúzva, úgy persze, hogy a kernel nem engedi nekünk az umountot (Ilyenkor a submountot kell első körben leszedni). Ezt könnyen ellenőrizhetjük is a mount paranccsal, de itt sajna ez se játszik, mivel nem volt egy submount se
- AIO/CIO használatban van?
- Ezen a rendszeren konkrétan pont egyik sincs, viszont ezek is képesek ilyen szintű lockokat összehozni. Viszont a HA épp ezért is próbálkozik 61x (ami itt közel 3 percig ment is), hogy az ilyen dolgokkal se legyen gáz, ha ne adj isten az AIO/CIO nem volt elég gyors adott pillanatban. Mint látható ez itt szintén nem jött be.
- Named Pipe?
- Egzotikum, viszont nem szabad figyelmen kívül hagyni.. Alapvetően Inter-process communication célokra szolgál olyan esetekben ahol a jogosultság szeparáció nem teszi lehetővé a normális IPC kommunikációt direkt memórián keresztül (Hozzáteszem, hogy ez inkább a régebbi appoknál bevett eljárá. Az AIX jó ideje tud direktben memóriában adatot átadni különböző jogosultsági szinteken futó alkalmazásoknak Shared Memory-n keresztül (szintén az IPC része). Ilyen esetekben az applikáció képes egy ilyen "pipe" file-t létrehozni, és sima chmod-os/ACL-es megoldással másik user alatt futó applikációnak átadni az adatot direktben. A probléma ezekkel viszont annyi, hogy nincs tényleges file írás/olvasás, mivel az egész hóbelebancot az AIX memórián belül képes lezongorázni, így meg a fuser se veszi észre, hogy a háttérben szopatják a népet, mivel az fopen/fwrite/fclose és hasonló eventekre figyel főként.

Persze kérdés, hogy hogy járunk ezeknek utána.
- Egyik módszer a http://p1ngw1n.blogspot.hu/2012/02/fuser-nemileg-maskent.html-ban felvázolt módszer
- Másik meg az lsof :)

Mivel az első módszert anno már lefedtem, így maradjunk az egyszerűbbnél, és nézzük, hogy az lsof-el mit is látunk ilyenkor :)
server@root:/ # lsof |grep /var/mqm/RGmount
runmqlsr_  933958 wasRGuser    6u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/ccc.933958
runmqlsr_  933958 wasRGuser    9u  unix 0xf100020000837c08             0t1728                     /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
runmqlsr_  933958 wasRGuser   12u  unix 0xf100020000736408             0t1852                     /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
amqzmgr0  1093830 wasRGuser    8u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe
amqzmgr0  1200368 wasRGuser    8u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
runmqlsr_ 1605678 wasRGuser    6u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/ccc.1605678
runmqlsr_ 1605678 wasRGuser    9u  unix 0xf100020002275408             0t1728                     /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe
runmqlsr_ 1605678 wasRGuser   12u  unix 0xf100020001ee7808             0t1852                     /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe

BINGO.. Innen már akkor csak akkor gyilkolásznunk kell :)
server@root:/ # kill -9 933958 1093830 1200368 1605678
server@root:/ # umount /var/mqm/RGmount
server@root:/ #
Innen pedig tovább lehet akkor lökni a HA-t is a túloldalra

A történet tanulsága:
- lusta embereknek kötelező az lsof (az experteknek meg a kdb :))
- A HACMP (attól függetlenül, hogy az idők során szinte mindenre próbálták felkészíteni) se tud mindent lekezelni
- A fejlesztőknek is van humora :)
- Murphy lehet, hogy köcsög mindig, de valahogy még is az ilyen szívásokkal tanulja meg az ember, hogy mennyire is halandó, és lényegében így tanulja csak meg azokat a leckéket, amikre más nem lenne képes megtanítani (se iskola, se oktatás, se certifikációk)

2012. augusztus 26., vasárnap

EPIC moments - Avagy miért születetthetett meg a pokoli operátor?

Az ember néha tényleg azt hinné, hogy a hülyeségnek azért valahol csak van határa, de időről időre rá kell döbbenjek, hogy az ami még tegnap tényleg jó viccnek tűnt, ma már lehet komor valóságként materializálódik a szemem előtt.

Álljon hát itt néhány kis szösszenet azokból az "URAM ISTEN" pillanatokból, amiket az elmúlt időszakban sikerült megtapasztalnom.

1) - "Van e elég hely a /dev/null alatt?"

Anno volt ez egy elszólása egy némileg távoli kollégámnak, amin sikerült jót vigadni. A dolog apropója annyi volt, hogy az egyik logfile-t átirányítottuk a /dev/null alá (mondván, hogy úgy se használjuk, csak ha debugolni kell) erre ő -féltve, hogy az FS megtelik- megkérdezte, hogy van e elég hely alatta.. Ez anno tényleg vicces volt, viszont amikor az ember ilyet lát, de most már kezdem azt hinni, hogy ilyen felszólalásokat Murphy felhívásnak érzi, hogy megcáfolja őket ; főleg amikor ilyesmi issue jön az emberrel szembe:
server@root:/ # df -m /
Filesystem    MB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4         192.00      0.00  100%     3694    85% /
server@root:/ # du -axk / |sort -rn |head -5
193860  /
109992  /dev
109956  /dev/null
27160   /etc
24272   /lpp
server@root:/ # ls -l /dev/null
-rw-------    1 root     system    112590848 Aug 23 19:55 /dev/null
server@root:/ # du -m /dev/null
107.38  /dev/null
server@root:/ # file /dev/null
/dev/null: commands text
Hogy az a jó élet.. WTF?? A /dev/null nem egy character file-nak kéne lennie? Dehogynem.. Akkor miért nem az?? A válasz: Mert valaki letörölte.. Az első jött ment process meg nyomban létre is hozta a file-t egy átirányítás révén ($command 2>/dev/null - szerintem mindenki látott már hasonlót :)), ami aztán lassan meg is telítette a / filerendszert..

* facepalm * ... Aztán akkor meg a gyógyszer:
rm /dev/null; mknod /dev/null c 2 2; chmod 666 /dev/null
Ha azt hiszitek, itt vége a sztorinak tévedtek!! Murphy úgy gondolta, hogy lesz 2. felvonás is:
server@root:/ # ls -l /dev/null*
crw-rw-rw-    1 root     system        2,  2 Aug 23 15:09 /dev/null
-rw-r--r--    1 root     system     20057274 Aug 23 13:54 /dev/null 2>&1
*sigh* Ez meg mi a lóturó...

Kis turkálás, majd az oka is megvan: http://www-01.ibm.com/support/docview.wss?uid=nas74d33539b559cc0308625792900533a8f
Igen.. A programozók ilyet is tudnak...

2) - Forkbomb sudo-val

A szituáció a következő: Megpróbálsz belépni a rendszerre, de a belépés sikertelen. HMC-ről látod, hogy a gép megy, de a gépet a virtuális terminálon át se sikerül elérni (a terminál megnyílik, de login screen-t nem kapsz). A gép lényegében vegetál, úgy hogy nincs más mint előre - force restart HMC-ről. A gép vissza is jön az életbe, persze az okot ekkor még nem tudjuk, tehát elkezdünk nézegelődni a logokban, hogy mi a fene van.. Rövid vizsgálódás után a shell közli velem, hogy "unable to fork"..
Őőő... Mi van??? És a gép tényleg ismét elkezdi azt amit előtte is: nem lehet vele semmit se kezdeni..
Újabb újraindítás, svmon-al nézzük, hogy mi zabálja a memóriát, de semmi különöset nem látok.. topas.. detto semmi.. ps lista.... állj..
server@user:/ # ps -ef
     UID      PID     PPID   C    STIME    TTY  TIME CMD
    root        1        0   0   Jul 05      -  0:06 /etc/init
    root  1441896        1   0   Jul 05      - 21:51 /usr/sbin/syncd 60
    root  1638488        1   0   Jul 05      -  0:00 /usr/ccs/bin/shlap64
    root  1769656        1   0   Jul 05      -  0:00 /usr/lib/errdemon
    root  2359508  8192170   0 17:57:36  pts/0  0:00 -ksh
    root  2424966  3145848   0   Jul 05      -  0:00 /usr/sbin/biod 6
    root  2556062  3145848   0   Jul 05      -  0:01 /usr/sbin/hostmibd
    root  2752642  3145848   0   Jul 05      -  0:02 /usr/sbin/syslogd
    root  2818192  3145848   0   Jul 05      -  1:35 sendmail: accepting connections
    root  2883696  3145848   0   Jul 05      -  0:02 /usr/sbin/snmpmibd
    root  2949226  3145848   0   Jul 05      -  0:26 /usr/sbin/aixmibd
    root  3014786 15335476   0 17:57:32  pts/0  0:00 -ksh
    root  3080398  4391120   0 17:57:29  pts/0  0:00 -ksh
    root  3145848        1   0   Jul 05      -  0:00 /usr/sbin/srcmstr
    root  3211378  3145848   0   Jul 05      -  0:00 /usr/sbin/snmpd
    root  3342544  4194544   0 17:57:33  pts/0  0:00 -ksh
    root  3407976  3145848   0   Jul 05      -  0:00 /usr/sbin/portmap
    root  3473514  3145848   0   Jul 05      -  0:00 /usr/sbin/inetd
    root  3539066  7864376   0 17:57:32  pts/0  0:00 -ksh
    root  3604658 10420352   0 17:57:33  pts/0  0:00 -ksh
    root  3735804  7536670   0 17:57:34  pts/0  0:00 -ksh
    root  3801268  7340182   0 17:57:32  pts/0  0:00 -ksh
    root  3866832  9044146   0 17:57:31  pts/0  0:00 -ksh
    root  3932166  7667938   0 17:57:34  pts/0  0:00 -ksh
    root  3997750  9764978   0 17:57:30  pts/0  0:00 -ksh
    root  4063286  4259944   0 17:57:31  pts/0  0:00 -ksh
    root  4128854 12910818   0 17:57:34  pts/0  0:00 -ksh
    root  4194544 12320872   0 17:57:33  pts/0  0:00 -ksh
    root  4259944  8978666   0 17:57:31  pts/0  0:00 -ksh
    root  4325470 13041670   0 17:57:35  pts/0  0:00 -ksh
    root  4391120 10223744   0 17:57:29  pts/0  0:00 -ksh
    root  4456662  3604658   0 17:57:34  pts/0  0:00 -ksh
...
    root 15335476 11337968   0 17:57:32  pts/0  0:00 -ksh
    root 15401026 12648676   0 17:57:36  pts/0  0:00 -ksh
    root 15532266 15204356   0 17:57:37  pts/0  0:00 -ksh
server@user:/ # ps -ef |grep -c ksh
245
őő.. ez kicsit sok nem?? Plusz mi a fenétől jöttek ezek elő??? Közben persze telik az idő, és ismét beüt a krach ; újabb restart, de most már sejtem, hogy mi a probléma , valamiért túl sok ksh forkolódik és sok kicsi sokra megy alapon mindegyik lefoglal magának egy kis memóriát, ami azért ekkora léptékben már képes megzabálni a gépet.. Úgy hogy az újraindítás után nyomban proctree-vel kezdem a játékot, s mit látok?
server@user:/ # ps -ef |grep ksh |tail -1
    root 1478878 1466588   0 18:20:10  pts/0  0:00 -ksh
server@user:/ # proctree 1478878
434214    /bin/ksh /etc/rc.itm1
   389164    -ksh -c /opt/IBM/ITM/bin/itmcmd agent start ul >/dev/null 2>&1
      462944    -ksh
         385246    -ksh
            405732    -ksh
               176296    -ksh
                  442614    -ksh
                     381148    -ksh
                        94260    -ksh
És innen meg végtelen sorokban ksh hegyek..

Na nézzük mi jön le ebből: Van egy 434214 PID-ű process-ünk ami épp egy ITM6-os indító script, ami meghívja az UL agent startupját, ami meg aztán hegyekben szórja a ksh-s forkokat.. Ahogy a hívásból látjuk egy ksh futtatja magában a /opt/IBM/ITM/bin/itmcmd file-t is (ergo az is script), ami meg init-ből indul..
Scriptet megnéztem - semmi különös - a szokásos hívások vannak csak benne.. Fejvakarás, wattafák.. Majd megpróbálok én is felmenni root szintre sudo-val, és furcsa módon tapasztalom, hogy bizony, shell-t azt nem kapok... Ctrl+C hegyekben, aztán csak kaptam shell-t..
Ez volt az a pillanat amikor már kezdtem azt hinni, hogy a root user-el van csak gond ( a user shellem gond nélkül ment), ergo belekukkantottam a root profile file-jába, és ezt a gyönyörűséget láttam:
server@root:/ # cat .profile
export ENV=.kshrc
# Define initial prompt to include hostname
export PS1=`hostname`@$USER':$PWD # '
sudo su -
ŐŐ.. Álj.. 'sudo su -' a root profiljában???? KI VOLT AZ A MARHA???? Profil átír, 'sudo su -' sor eltávolít, rendszer ujraindít, minden működik szépen.

Na de mi is történt? - valamelyik ökör belerakta a root profiljába a 'sudo su -' sort.. Miért is gond ez? Mert a 'sudo su -' a root user alatt kérdés (meg jelszó kérés) nélkül lefut, és egy újabb shell-t nyit, ami meg megint beolvassa a root .profile-ját, ami így megint lefuttatja a 'sudo su -'-t és így tovább amíg a szerver bírta...
Ergo valaki ügyesen fork bomb-á alakította a sudo-t root alatt :)

3) - Az öngyilkos java alkalmazás

Anno még írtam is az egyik szép kis kamikáze kódról, ami sikeresen szembe jött velem.. Most újra elő kell vegyem a témát, mert az amit láttam az nem hogy ennek egy emeltebb formája volt, mintsem egy komplett seppuku :)
Na szóval... Van egy szerver, egy rajta futó Websphere (Web's Fear) alkalmazással rajta, amin belül meg fut egy valaki által írt applikáció jópár éve..
Egyik nap megszólal a vészharang, ügyfél sikoltozik, hogy a hőn szeretett alkalmazása nem működik.. Jó, rendben nézzünk utána.. Kis nyomozás, közös munka az application support group-al, majd kiderül, hogy hiányzik az alkalmazás "magja". Pontosabban ott van, csak nem úgy működik, ahogy kéne (azaz sehogy).
Az elején még nem értettem miről van szó, de aztán lassacsakán megvilágosodtam.. Íme egy röpke összefoglaló arról, hogy mi történt (időrendi sorrendben)
- Jópár éve már, hogy valami fejlesztő palánta megírta az alkalmazás core modulját
- Ez a modul jópár évig gond nélkül, aztán beütött a krach - Az applikáció összeomlott, majd nem volt képes újraindulni.
- Az applikáció HOME könyvtárában lévő core file elemzése után kiderült, hogy az alkalmazás egy verem hiba miatt esett össze, majd a szokásos módon dobott egy java core-t. Mindezt egy olyan applikációs almodul játszotta el, amit közvetlenül a fő mag hívott
- Aki még nem találta ki, annak itt a csattanó - Igen, az applikáció magját 'core'-nak hívták.. Ezt volt a file neve..

Tehát mi is történt: Volt egy core nevű alkalmazásunk, ami szépen futott, míg az egyik almodulja (ugyan abból a HOME-ból futtatva) nem dobott egy coredumpot, ezzel szimplán felülvágva az eredeti 'core' file-t, innentől meg az alkalmazás központi magja nem volt elérhető, ergo persze, hogy nem is indult el ez után.

És egyesek még csodálkoznak, hogy az IT-sok néha "kicsit" idegesek.. El nem tudom képzelni miért..