Ránézek a szerverre: pingelni lehet, barmiféle kapcsolatot nyitni viszont nem.
HMC-ről nyitott virtual konzolról megvizsgálva a kérdést se jobb a helyzet, csupán a temérdek "unable to fork" hibaüzenet igazolja az eddigi teóriát, hogy bizony itt elfogyott a gép alól a fizikai memória, és még csak azért van életben, mert a paging space-ből még maradt valami ahova ki lehet lapozni azt a kevés memória területet amit a rendszer képes volt felszabadítani.
Mit lehet ilyenkor tenni? A lehetőségeink lényegében az alábbi 3 opcióra korlátozódnak:
- Imádkozunk, hogy a terhelés egy idő után megszűnik, és felszabadul annyi memória, hogy a szervert ismét életképes állapotba lehessen hozni
- Várni hogy az OOM killer végre működésbe lépjen, vagy hogy a rendszer összeessen magától
- Manuálisan újraindítani az egész mindenséget és behúzni +1 strigulát a service outage rubrika mellé
A kérdés már csak az, hogy a 3 opció közül melyik az, amelyik számunkra ÉS a customer számára is elfogadható. Jó, beszélgessünk el a customerrel, hogy akkor mi és hogyan, illetve próbáljunk meg rájönni, hogy melyik opciót is érdemes választani. Valami ilyesmit képzeljetek el:
- A szerviz számára fontos a szerver?
- Naná hogy az, production szerver, 7x24ben elérhetőnek kéne lennie
- A fontosabb szolgáltatás(ok) elérhető(ek)?
- Hááát ami azt illeti igen, csak épp lassú mint a fene.
/* tehát nincs szerviz kiesés, ami azt jelenti, hogy a fontosabb programok még a memóriában elvannak valahogy és onnan még tudnak úgy-ahogy működni is*/
A fontosabb dolgok hála az égnek mennek, de például az utóbbi 4 beütemezett job failed-re futott /* naná, valószínű el se tudott indulni */
- A nem elérhető részek mennyire business kritikusak?
- Hát.. Kis kiesés még belefér, de hosszútávon már komoly problémákat okoz ha a jobok nem futnak le.
- Tudnak e olyan jobról ami ebbe az idő-ablakba lett ütemezve, és esetleg erősen erőforrás igényes lehet?
- Nem, azok a hétvégére vannak csak beütemezve
- Jó. Tehát a szerviz még elérhető, bár funkcionálisan korlatozott. Mivel jelenleg nem tudunk a rendszerről barmit lekérni, így sajna megbecsülni se tudjuk hogy ez a hibajelenség tartós avagy ideiglenes e. A rendszer teljes újraindításával biztosan vissza tudjuk állítani a rendet, viszont az a szolgáltatás ideiglenes, ám teljes kiesésével is jár. Kérdés hogy ez a szerviz szempontjából elfogadható e, vagy inkább várjunk még egy kis időt, hogy hátha magától megszűnik a magas memória terhelés?
- Hát.. A szolgáltatás szempontjából a helyzet nem kritikus, viszont így nem is lehet a rendszert adminisztrálni. A következő fontos job kb 2 óra múlva indulna. Ha az se tud lefutni, az már komoly pénzbeli veszteség lenne a cégnek. Kb mennyi időt vesz igénybe a teljes rendszer újraindítása?
- Az újraindítás viszonylag gyorsan megvan, a visszaellenőrzések viszont eltartanak egy minimum 20 percig. Számoljunk 30 percet mindenre biztos ami biztos.
- Rendben. Akkor még kb 1 órát tudunk várni, és akkor még lesz 30 percünk az esetleges hibaelhárításra. Ha addig se jön helyre a szerver, akkor indítsák újra.
Ok.. Kapott a szerver 1 óra haladékot, hogy bebizonyítsa milyen fából is faragták. Közben azért érdemes elgondolkodni, hogy mi is mehet épp végbe az AIX mélyebb bugyraiban (kernel szinten):
- A rendszer már kidobált minden nem szükséges adatot a fizikai memóriából (temporary cache már tuti nincs, ami még kell és kilapozható az meg már biztosan a paging space-en található)
- Ettől függetlenül a fizikai memóriában nincs szabad hely, ergo új process-t se lehet nyitni/forkolni. /* épp ezért nem is lehet belépni a gépre, mivel ott is minimum egy új shell-t kéne forkolnia a rendszernek */
- Azok a processek amik már a memóriában vannak még képesek funkcionálni /* ezért is képes a szolgáltatás még úgy ahogy életben maradni */
- A rendszer folyamatosan törekszik kiszolgálni a bejövő memória igényeket, illetve fizikai memóriát felszabadítani további page-ek kilapozásával.
- Amennyiben az egységnyi idő alatt bejövő memória kérések száma magasabb mint amit a rendszer adott idő alatt fel tud szabadítani, akkor lényegében egy meglehetősen kellemetlen hógolyó effektus következik be, mivel a futó program által kért memória terület biztosan valami adat számára lett kikérve, - amit a rendszer viszont ilyen esetekben hajlamos gyorsan ki is lapozni - ami viszont csak tovább rontja a helyzetet, mivel a diszken lévő paging sebessége kb egy kerékbilincses csigáéhoz hasonlítható a fizikai memóriához képest => ilyen helyzetben a nagy paging space csak a haláltusát hosszabbítja meg, de ténylegesen nem segít semmit /* főleg ha a process még később vissza is akar olvasni valamit amit a rendszer ma előzőleg kilapozott */
- Ez az állapot addig fennáll amíg az elérhető virtuális (!) memória le nem csökken egy bizonyos szintig: Amikor az elérhető virtualis memory page-ek száma eléri az VMO npswarn értékét (4k-ban tessek számolni), akkor a rendszer kiküld mindenkinek egy SIGDANGER signalt, hogy lehetőséget adjon a processeknek konzisztensen leállni (már ha fel vannak készítve arra hogy az ilyen signal-al kezdjenek valamit). Amennyiben a memória kihasználtság ez után eléri a VMO npskill értékét (vagy mert a programok ignorálták a signalt, vagy mert nem bírtak időben leállni), akkor a kernel szisztematikusan elkezdi legyilkolászni a legfiatalabb processeket amikre "engedélyé van": Ez kb annyit jelent, hogy a process owner UID-ja nincs felsorolva a VMO nokilluid listáján /* alapból pl a 0as UID van ott, ami annyit jelent, hogy a root neve alatt futó processeket a rendszer nem fogja legyilkolni */
- Amennyiben a rendszer nem képes ezzel a módszerrel se memóriát felszabadítani akkor a paging space teljes felhasználása után egy garantált system crash következik, amit aztán egy automatikus restart követ.
A fenti példából azért látszik, hogy van olyan forgatókönyv is, amikor a szerviz számára fontos programot a rendszer nemes egyszerűséggel legyilkolja (már ha a hozza köthető UID nincs rajta a nokilluid listán), ami kb csak 1 fokkal jobb csak a teljes újraindításnál :)
#Megjegyzés - ez azt is jelenti, hogy a fenti VMO paraméterek finomhangolásával amúgy simán életben is lehet tartani egy gépet restart nélkül, csak akkor készüljünk fel arra, hogy időnként 1-2 programot lehet újra kell majd indítgatni.
Eltelt 1 óra.. Sajnos a rendszer nem volt képes visszarángatni magát a valóságba, így az ügyfél kérésére azt újra kellett indítani. Na jó.. de hogyan? Ne tessek félre érteni, nem az a kérdés, hogy milyen paranccsal, vagy min keresztül (HMC azért jó ha van :)). A kérdés inkább arra irányul, hogy azonnal újra kell e indítani mindent, vagy esetleg adunk a rendszernek még 1-2 percet hogy ha már eddig eljutott akkor dobjon már egy system dumpot is, amiből esetleg később még tudunk vizsgálódni. Ismerve a managementet, az utóbbi garantáltan megfontolandó (még akkor is ha nem azonnal indul újra az LPAR), tekintve, hogy biztosan el fog hangzani az a kérdés, hogy "Jó, de mi tömte tele a memóriát?"
# Jó tanács: Mielőtt a Windows-on nevelkedett adminok nekiállnának azonnal újraindítani 1-1 gépet, inkább tanulják meg az alábbi parancsot használni HMC-ről:
chsysstate -m $MACHINE -r lpar -o dumprestart -n $PARTITION
Kb 5-10 percbe telt mire a gép mindent kidumpolt a memóriából, majd elkezdte szépen újraindítani a rendszert, amit gyors program indítgatások és visszaellenőrzések követtek, így a szerviz ismét teljesen elérhető lett és a customer számára kritikus job is le tudott futni minden gond nélkül.. Éljen.. An other success story, good job, well done, champaign.. Na jó, nem egészen..
További kb 1-1,5 órán át még ment a beszélgetés illetve az összefoglalók írása, miután elhangzott customer oldalról az a kérdés amire előzőleg egy meglehetősen nagy fogadást mertem volna kötni: "Ki tudjuk deríteni, hogy mi okozta ezt? Vagy van valami módszer arra, hogy ezt megelőzzük?"
Látjátok, mondtam én :)
Mázlira a dump device-al, és annak beállításaival semmi gond nem volt (dump compression bekapcsolva, dump device mérete megfelelő) és volt is elég hely ahhoz, hogy a dumpot kimásolva egy fájlrendszerre, majd kitömörítve el lehessen kezdeni analizálni, hogy végül is mi a franc volt a géppel.
Persze ahhoz hogy ezt megválaszoljuk azért nem árt tudni, hogy mi is helyezkedik el a memóriában. A teljesség igénye nélkül itt egy kis összefoglaló:
- A kernel számára lefoglalt memória terület (erre szoktak még System occupied memory néven is hivatkozni, ami magában foglalja magát a kernelt (és annak moduljait), a kernel heap-et, a shared memory szegmenseket, memory buffert, kernel cache-t, és a shared library-knak fenntartott memória területet)
- Fájlrendszer cache /* AIX esetében ez JFS, JFS2, NFS cache-t jelent */
- Különböző HW-ek számára fenntartott caching area
- Processek indító binárisainak (futó process binárisa kötelezően a fizikai memóriában helyezkedik el) és esetleges privát library-knek fenntartott memória terület
- A processek számára fenntartott privát memória területek (minden processnek saját memória terület, saját virtuális memória címzéssel)
Kezdjük is azzal ami a legtöbb problémát szokta okozni: Azok a fránya programok. Csak hogy szemléltessem hogy mennyire (nem)vicces tud egy ilyen nyomozás lenni, már itt leszegezem hogy ennek vizsgálatára nyomban 3 különböző módszer van, amik mind mást-mást néznek (ergo más-más eredményt is produkálnak) ... csak hogy az ember élete egyszerű legyen ...
- a kdb-nek van beépített svmon parancsa, ami meglehetősen jól visszaadja az aktuális állapotot, viszont bizonyos helyzetekben hajlamos nem működni. Naná hogy ez is pont egy olyan helyzet:
(0)> svmon * Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd LPage [kdb_read_mem] no real storage @ F10013AE4747FF70
- Minden process-től ki lehet kérni az éppen lefoglalt fizikai és paging lapokat (nvpages és npsblks értékek) a proc alparancs segítségével, viszont összehasonlítva egy (működő) svmon kimenetével egyértelműen látható, hogy ez nem a ténylegesen lefoglalt összes virtuális memóriát adja vissza, hanem annak csak egy részét (az svmon kimenetéből csupán a working storage és shared library data összegét vagyunk képesek így megállapítani; a heapet, illetve a kernel segment-eket nem). További kellemetlenség, hogy ezt minden egyes processre meg kell vizsgálni, ami vagy egy script formájában történhet meg, vagy sok, türelmesen beírogatott proc es grep parancsok kombinációjával /* a script lassú, kézzel meg még lassabb - marad a script */
# Megjegyzés - már itt látható, hogy még így is lesznek később problémáink a processek pontos behatárolásával, tekintve, hogy a "java" process rohadtul nem mondja meg, hogy a JVM-en belül mi futott. Erre később még visszatérünk.# for i in $(echo 'proc *' |kdb dump_file_copy|awk '{print $1}') > do > echo "proc $i" |kdb dump_file_copy |awk '/ nvpages/ || /^pvproc/ {print $3}' | \ > awk 'NR == 1 { printf("%s", $0); } NR != 1 { printf(" %s", $0); } END { printf("\n") }' > done |sort -r -k2 |sed "s/://g" |head -10 java 000000000001F7FC -> ~ 503.9 MB java 000000000001545D -> ~ 340.3 MB java 0000000000007A43 -> ~ 122.2 MB java 00000000000065F0 -> ~ 101.9 MB kuxagent 00000000000024A1 -> ~ 36.6 MB java 0000000000001951 -> ~ 25.3 MB k07agent 000000000000140F -> ~ 20 MB cimserve 0000000000001088 -> ~ 16.5 MB kulagent 0000000000000C37 -> ~ 12.2 MB aixdp_da 0000000000000C02 -> ~ 12 MB
- az scb alparancs segítségével is ki lehet kérni az nvpage-eket (process azonosítóra szűrve), itt viszont már a rendszerhez rendelt page-ek is listázva lesznek, ergo szerintem ez a leghasználhatóbb módszer (már ha az svmon valamiért nem működne), plusz az előzőhöz képest jóval gyorsabb is az alap vizsgalat (mivel a page-eket egy körben le tudjuk kérni), viszont itt az is bejön, hogy 1 process több page-et is használhat (már ha többszálusított programról beszélünk), így ezt a vizsgálat során külön figyelembe kell venni. Ezen felül a szűrt processekre (mondjuk top10) így is kell egy extra fork a proc alparanccsal, szóval hiába gyorsabb, attól még azért eléggé macerás így is:
# PVPROC_=""; VPGS_="0" # echo "scb -c 6 0" |kdb dump_file_copy |grep -v 0000000000000000 |grep -w W |awk '{print $10,$7}' |sort | \ > awk '{gsub ("MB","")}{if ($2 ~ "GB") {sub ("GB","");print $1,$2*1024,$3} else {print}}' | while read PVPROC VPGS > do > if [ "${PVPROC}" == "${PVPROC_}" ] > then > VPGS="$(echo ${VPGS_}+${VPGS} |bc)" > else > echo "${PVPROC_} ${VPGS_} ${PGSP_}" > fi > PVPROC_="${PVPROC}" > VPGS_="${VPGS}" > done| sort -rn -k2 |head -10|while read PROC VPGS PGSP > do > printf "%-15s %-15s %-15s\n" \ > $(echo "proc $PROC"|kdb dump_file_copy |awk '/^pvproc/ {printf ("%d %s", "0x"$5, $3)}') "${VPGS} MB" > done 15597570 java 571.6 MB 7274716 java 374.1 MB 4653250 java 271.1 MB 14745724 java 102.9 MB 0 swapper 83.7 MB 3866808 rmcd 61.6 MB 6094860 java 50.3 MB 10354744 kuxagent 38.0 MB 8192024 cimserve 31.5 MB 6946818 k07agent 22.5 MB
Szupi.. akkor most már van valami hozzávetőleges fogalmunk is arról, hogy mi mennyit zabált. nézzük mennyi memória is alt rendelkezésre:
Őőőőőő.. Állj.. A számok valahogy nem stimmelnek: Ha megnézzük, akkor az top10 process is csak kb 1.6 GB-ot volt képes lefoglalni, ami közel sincs a teljes 3.6 GB-hoz (HW cache nélkül). Ami azt jelenti, hogy valamit vagy nagyon sikerült benézni, vagy máshol van Lessie elásva. 1 lépés előre, 3 lépés vissza, kezdjük elölről, de most inkább kezdjük a vizsgálódást magasabb szintről és csak utána menjünk alacsonyabb szintekre:(0)> vmstat |grep "total lru frames" total lru frames (4K units) : 00000000000E53E0 3.6GB
Fizikai memória (poolonként lebontva - mázlira itt csak 1 pool volt)
3700 MB (3.6 GB) fizikai memória összesen, ebből 8,8 MB szabad a dump pillanatában. Eddig stimmt. Nézzük a paginget(0)> memp * VMP MEMP NB_PAGES FRAMESETS NUMFRB F1000F0009540000 00 000 000E7440 000 001 002 003 000008D4 ^^^^^^^^ ^^^^^^^^ 3700.25 MB 8.8 MB
6.625 GB paging, ebből közel 4.2 GB szabad. Eddig is klappol a történet.(0)> vmker |grep pgsp |egrep "^total|^free" total pgsp blks (numpsblks) : 001A8000 -> 6784 MB free pgsp blks (psfreeblks) : 0010DDE4 -> 4317.8 MB
Na jó, itt kicsit sok dolog van, beismerem. Nézzük őket szépen sorjában(0)> vmstat |egrep "total perm frames|wlm_hw_pages|vm_nonsys|total perm frames|vm_syspgs" # 'system' pages (vm_syspgs) : 00000000000E2844 3.5GB # non-'system' pages (vm_nonsys) : 00000000000041F8 66.0MB total perm frames (4K units) : 0000000000000187 1.5MB Total unmanaged mem (wlm_hw_pages): 00018BC0 395.8MB
- 'system' pages / vm_syspgs - Emlékeztek még a fent említett "kernel-számára fenntartott memória terület"-re? Na ez az :)
- non-'system' pages / vm_nonsys - Fizikai memórián belül azon processekhez tartozó lapok mennyisége amik nem lettek kilapozva a paging space-re
- total perm frames - fájlrendszer cache (JFS, JFS2, NFS)
- Total unmanaged mem / wlm_hw_pages - A szinten fent emlegetett HW cache area.
Na itt már látszik, hogy nem mi vagyunk a hülyék, hanem a rendszer tényleg nagyon élszált, tekintve hogy a fizikai memóriában szinte csak system lapok voltak, a többi meg vagy HW cache, vagy applikáció, egy nagyon kevés FS cache, illetve 1 kis rész ami ezen a query-n nem látszik. Továbbá az is simán látszik, hogy a fenti svmon/proc/scb mérésünk semmit nem ér, ha nem látjuk, hogy mennyi memória terület is lett kilapozva abból amit az applikáció tényleg lefoglalt. Az viszont tuti, hogy a kernelnek nem kéne ennyit lefoglalnia, szóval nézzünk már rá, hogy mi a franc is zabált annyit:
Hat én itt 2 dolgot latok: Rohadt sok Kernel heap-et, meg egy kevéske memory buffert.. Ami azt jelenti, hogy az elején valóban nem benézés esete forgott fent, hanem a rendszer tényleg "Mind megette" játékot játszott, ami viszont némi kis keresgélés után nyomban ki is derül miért:(0)> scb -c 6 100 |grep 0000000000000000 |sort -rn -k4 |head -15 00A14A W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A148 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A147 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A146 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A145 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A144 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A143 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A142 W 64K 256.0MB 256.0MB 0.0MB 256.0MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A149 W 64K 255.8MB 255.7MB 0.0MB 255.8MB 0.0MB 0000 0000000000000000 KHEAP SYS 00A023 W 64K 206.7MB 203.4MB 0.0MB 206.8MB 0.1MB 0000 0000000000000000 KHEAP SYS 00A00E W 64K 187.8MB 53.8MB 0.0MB 188.0MB 0.2MB 0000 0000000000000000 KHEAP SYS 00A14B W 64K 154.1MB 153.9MB 0.0MB 154.1MB 0.0MB 0000 0000000000000000 KHEAP SYS 00E000 W 64K 130.0MB 130.0MB 0.0MB 130.0MB 0.0MB 0000 0000000000000000 MBUF SYS 00A111 W 64K 122.8MB 0.8MB 0.0MB 122.9MB 0.1MB 0000 0000000000000000 KHEAP SYS 00A01C W 64K 87.3MB 86.9MB 0.0MB 87.3MB 0.1MB 0000 0000000000000000 KHEAP SYS
IV53587: XMGC NOT TRAVERSING ALL KERNEL HEAPS. APPLIES TO AIX 7100-03 14/04/17 PTF PECHANGE
És igen... Persze hogy a rendszer pont ezen az szinten fut:
Customer értesít, állapot elmagyaráz (csak amolyan konyhanyelven, mert az halál biztos, hogy nem akarok 2 órán keresztül arról magyarázkodni -egy jó esetben félig technikus emberkének - hogy az AIX hogyan is manageli a memóriát a motorháztető alatt), következő maintenance window lefoglal, change előkészít, rendszer frissítés a hétvégére beütemez, hátradől, virtuális vállveregetés, a rendszergazda megpihen.# oslevel -s 7100-03-01-1341
Megpihenne.. Legalább is ha nem baxná az ideg, hogy mi a jó büdös francért kellett kb 2-3 órán át a kernel dumpot túrnia és a fejét vakarnia amikor különböző okoknál fogva valami vagy nem működött, vagy nem azt az eredményt adta amit az ember várna tőle. Mit csinál ilyenkor a (jó)rendszer gazda? Füles be, elkezd valami kódolós zenét hallgatni majd elkezdi az egész francos memória checket lescriptelni, hogy legközelebb már 5 perc alatt meglegyen az, amivel most órákat szívott.
És mivel jófej rendszergazda tudja milyen xar amikor mások is ilyenekkel szívnak, így inkább úgy dönt, hogy szabadon elérhetővé teszi az egészet, szóval ha ne adj isten más is hasonló aljasságokra adná a fejet, az használja szeretettel az alábbi kis scriptecskét arra hogy valami támpontot kapjon a rendszer állapotáról egy sikeres dump után:
https://drive.google.com/file/d/0BzMqRqSWTAToNjdCbUNXd1ZGeVU
A gyengébbek kedvéért azért azt kiemelném hogy az ilyen jellegű outputot is a helyén kell kezelni, ergo akinek nincs tapasztalata ilyen jellegű debugolásokban, annak inkább azt ajánlom, hogy max a scriptet olvasgassa, és próbálja meg megérteni hogy mi és hogy működik mielőtt teljesen vakon megbízna egy netről letöltött scriptben/parancsban :D
Csak úgy a hova tartás végett: a script jelenlegi verziója ilyen outputot generált a fent említett dumpból:
Ami a process neveket illeti.. Hát az tényleg a szívás kategóriába tartozik: logikus lenne, hogy a parancs argumentumait is megtaláljuk a memóriában (hisz itt van a /proc alatt, ami meg teljesen memória rezidens), a probléma viszont az, hogy ezt minden process saját maga manageli a saját kis memória területen belül (pontosabban mondva a process-nek fenntartott Guardpage-en belül; a procfs-en belül a psargs meg erre a memória címre mutat), így azt a kernel dumpból nem fogjuk tudni kinyerni direktben...# kdb_memory_check.sh -d dump_file_copy -t 10 Available physical memory: 0.215% (8.828 from 4096 MB ) HW pages: 395.750 MB (9.661% of total memory) FS cache: 1.527 MB (.037% of total memory) Processes occupied memory: 64.441 MB (1.573% of total memory) System occupied memory: 3624.265 MB (88.483% of total memory) Kernel Heap: 3320 MB (91.606% of system memory) Available paging space: 63.648% (4317.890 from 6784 MB) Additional details: SIGDANGER level: 54272 SIGKILL level: 13568 minperm percent: 3.0% maxperm percent: 90.0% maxclient percent: 90.0% Top 10 memory consumer(s) (based on nvpages) Process Name PID Virtual Pages Paged pages java 15597570 571.6 569.9 java 7274716 374.1 372.2 java 4653250 271.1 270.7 java 14745724 102.9 102.3 swapper 0 83.7 24.8 rmcd 3866808 61.6 61.1 java 6094860 50.3 49.8 kuxagent 10354744 38.0 36.8 cimserve 8192024 31.5 31.3 k07agent 6946818 22.5 20.6
Viszont ha mázlink van és megmaradt a process név+PID páros valamelyik bufferban/cache-benm akkor simán megpróbálhatunk ezekre rá-greppelni a dumpon belül és megszerezni a teljes process nevet, annak minden argumentumával együtt :)
Na és ezzel tényleg ennyi.. It's Now Safe to Turn Off Your Computer. Legalább is amíg a következő nagy "kihívás" nem köszön be..
Kezdjük is a kernellel, ha már a gyanúsítgatásnál tartunk (
