To ze nejaky program pada sa da akceptovat - nikto nie je neomylny.
To ze program nevie o svojom behu resp. pade zrozumitelne informovat, t.j. tak aby mal uzivatel o probleme aspon predstavu aj bez absolvovania skoleni je neakceptovatelne!
Naprogramujem to jak prasa, aby sa som na hotline supporte a skoleniach poriadne nabalil! pekne! :(
Z (titulku) Vaseho komentare mam dojem, ze se snad snazite vyprovokovat flame.
Jsem z Vas celkem rozpacity, nicmene si dovolim nekolik poznamek.
Za prve, cilem tohoto skoleni rozhodne neni "se nabalit" - viz zertovne slovicko zdarma na strance s kompletni pozvankou. Ze strany Sunu, tim spise lektoru, se jedna o dobrovolnou iniciativu "zdola".
Za druhe, pokud je to mozne, Solaris pri panicu vypise na konzoli prehlednou hlasku, vcetne kerneloveho stacku kodu, ktery panic zpusobil. Vetsinou to ale porad neni dost informaci na to, aby bylo mozno urcit root cause problemu. V takovych pripadech jiste ocenite moznost ziskat vsechny potrebne informace z crash dumpu, ktery pro Vas kernel vygeneruje.
Za treti, nekdy je ten crash dump to jedine, ce vam po panicu zbude, protoze konzolovy vystup proste nemusite mit sanci videt. Urcita kategorie crash dumpu pochazi ze "zamrznutych" systemu. Jak chcete docilit toho, aby Vam deadlocknuty system neco vypsal?
Mozna jste jen spatne pochopil ucel kurzu - nejde o to rict "chyba cislo 12345 znamena toto: 'bla bla bla'", ale cilem je opravdu naucit lidi logickym zpusobem zanalyzovat pripadny crash dump.
Proste bych Vam rad sdelil, ze debugovani rozhodne nekonci u prikazu printf/printk. Ostatne, muzete se do naseho kurzu prihlasit, treba se naucite neco noveho.
Docela by mě zajímalo, jakým způsobem se ten crash dump na disk zapisuje.
--- pokud kernel spadne kvůli poškození nějaké struktury, kterou používá ovladač disku, tak pak ovladač disku nelze pro zapsání crash dumpu použít (neboť znovu spadne :-). Je tam nějaký druhý ovladač speciálně na crashdumpy nebo se to píše biosem nebo se prostě doufá, že to při zapisování crashdumpu znovu nespadne?
Muzete si nastavit tzv. dump device, to je zarizeni, kam se ten dump zapise. Obycejne to byva nastaveno na swap. Po rebootu se to potom z toho dump devicu vyzvedne a nakopiruje do /var/crash/`hostname`/.
Z duvodu zminenych ve Vasem prispevku by bylo nejlepsi, kdyby ten "dump device" mohla proste byt pamet a na disk by se dump zapsal az po rebootu. Myslim, ze o takovem reseni jiz nekdo uvazoval, ale nevim, jak daleko to dospelo. Ted bych si tipnul, ze se doufa, ze to nespadne podruhe.
Nevim jestli to pisu presne, ale Solaris na SPARC dokazal zapsat crash dump tusim i bez ucasti OS. OPB nejak vedel kde jsou diskove cache a mozna i buffer console a dokazal to dumpnout do swapu. Ale mozna jsem mimo.
Nevím, jak to funguje v Solarisu, ale jedním z řešení tohohle problému je v případě pádu nabootovat druhé jádro, které pak ten crash dump zapíše. Myslím, že takhle funguje linuxový Kdump.
Tak tak, kdump si naalokuje souvislou oblast paměti jádra a vrazí tam dumpovací jádro. Pak je jen třeba se modlit, aby při crashi nebylo samo poškozené, ale proti tomu by se stejně šlo bránit asi jen něčím jako hypervizor, což nelze aplikovat všude.
Double crashdump se uz neresi, protoze v tuto chvili uz nemate jistotu vubec o nicem. Pak uz jen vyfasujete vetsi vypis stavu na konzoli a system se restartuje. Potkat double crashdump ale neni az tak moc obvykle, pro zapis crashdumpu se uziva castecne separatni cesta, tak, aby sance ji poskodit, se minimalizovala.