Kexec – výměna jádra bez restartu (diskuse)

[sivlk]

Aspon 1 vetou ste mohli zmienit ksplice

[Mrkva]

ksplice s kexecem zase tolik společného nemá. Navíc je to (řekl bych) dost nesmyslný projekt.

[trekker.dk]

Přesně, kdo by taky mohl chtít opravit bezpečnostní chyby bez restartu a downtime...

[Mrkva]

Tak tahle myšlenka je skvělá. Bohužel tam jsou ale nějaké ta "ale" :) Osobně raději překousnu několikaminutová downtime než abych instaloval binární patche do jádra od nějaké (skoro) neznámé firmy. Navíc, když se to vys... tak je mnohem lepší, když systém nenaběhne po rebootu než když spadne za běhu. A klidně při špatném patchi může dojít k poškození běžícího jádra. Případné následky snad jsou každému jasné..

[trekker.dk]

Osobně raději překousnu několikaminutová downtime než abych instaloval binární patche do jádra od nějaké (skoro) neznámé firmy.

Ty možná jo. Pokud má někdo na stroji úlohu, co běží dlouho a ještě dlouho běžet bude, určitě se mu nebude chtít pouštět to znova, protože restart

Patche původně nebyly binární, mělo to jít do hlavní řady...

[David Watzke]

To je pravda, ale v takových případech je IMHO lepší implementovat resume. Dobrovolnej restart je totiž jen jedním z mnoha důvodů (a to ještě takovej šetrnej), kvůli kterým se taková úloha může přerušit... Primárně jde asi o ten uptime, i když samozřejmě to, že se taková úloha neukončí je ve většině případech prima bonus.

[trekker.dk]

Po ksplice existuje poptávka, takže naprosto zjevně existují úlohy, které běží dlouho a resume neumí.

[Mrkva]

Ty možná jo. Pokud má někdo na stroji úlohu, co běží dlouho a ještě dlouho běžet bude, určitě se mu nebude chtít pouštět to znova, protože restart

To urcite. Ale porad je lepsi, kdyz ten nekdo tu ulohu pozastavi kvuli restartu, a po restartu da resume a bude pokracovat, nez kdyz mu uprostred behu te ulohy necekane sleti system, protoze spatny binarni patch. To v tom lepsim pripade - v tom horsim pripade to zdanlive probehne OK a treba to poskodi driver radice a skoncis s filesystemem na hadry.

[trekker.dk]

protoze spatny binarni patch.

Já nevím, co furt máš s těmi špatnými binárními patchi... ty patche se vytváří z aktuálního běžícího jádra (tj. z otevřených zdrojových kódů), nahradit tělo funkce jinou taky není tak velký problém a největší problém celého toho procesu jsou softwarové patenty na některé částí postupu.

Tvoje kecy o špatných patchích jsou jenom FUD. Nebo už jsi nějaký takový pád kvůli ksplice viděl?

[Mrkva]

Ja jen tvrdim, ze opatchovani jadra za behu muze mit (v pripade spatenho patche) mnohem katastrofalnejsi nasledky, nez reboot. Nesouhlasis?

Netvrdim, ze k necemu takovemu uz nekdy doslo, ale tvrdim, ze k tomu dojit muze.

[Grunt]

K tomu by spíš byl vhodný nějaký mechanismus, který by uměl vyměnit jádro a přitom by nezabíjel user-space.

[MX]

Zapomels na armboot ... to byl takovy kexec pro ARM

[____]

Já kexec beru za trochu rychlejší reboot, nic moc většího jsem v tom nenašel. S některými zařízeními může být problém.

[Grunt]

Kdo nehledá nenajde. Já např. u Linuxu oceňuju ovladače snad ke každému myslitelnému zařízení. Takže v případě použití nějakého minimálního jádra, ovladačů a kexecu je možné toto jádro použít jako zavaděč, takového předskokana běžícího velkého jádra. Já ho např. používal k bootu z CD-ROMky (USB) na zařízení na kterém jsem neměl dostupné krom disketovky snad nic a o bootu z USB zařízení BIOSem jsem si mohl nechat jenom zdát.

[David Watzke]

Mimochodem, po odeslání článku jsem upgradoval z 2.6.35.7 na 2.6.36 pomocí kexec a fungovalo to skvěle, jako kdybych počítač rebootoval. Jelikož tato verze jádra opravila několik neduhů, které se v 2.6.35.x objevily, o to milejší překvapení to bylo.

PS: kdyby to někoho zajímalo, tak uptime se samozřejmě vynuluje.

[Grunt]

Tak nějak to funguje přibližně na všech distrech (vim min. o Ubuntu a Fedoře). Např v Ubuntu se to po instalaci balíčku nastavuje v /etc/default/kexec a ten vypadá následovně:

# Defaults for kexec initscript
# sourced by /etc/init.d/kexec and /etc/init.d/kexec-load

# Load a kexec kernel (true/false)
LOAD_KEXEC=false

# Kernel and initrd image
KERNEL_IMAGE="/boot/vmlinuz-2.6.32-22-generic"
INITRD="/boot/initrd.img-2.6.32-22-generic"

# If empty, use current /proc/cmdline
APPEND="root=UUID=00ece7dc-da9e-43e1-b8f3-50fad256d916 ro single kgdb8250=ttyS0,115200 kgdbwait kgdbcon"

v lepších případech stačí jen LOAD_KEXEC=false přepsat na LOAD_KEXEC=true a bude to fungovat samo. Jinak s tím nedefinovaným stavem to není až tak úplně žhavé. Důležité je, aby k zařízení kupř. byly jaderné ovladače a byla v nich zahrnuta inicializace. Dřív býval např. problém s grafikama, ale co je v jádře Noveau a KMS, tak to fachčí bez nejmenšího problému. Jinak si se klidně pár slovy ještě mohl zmínit o kdumpu. Ten je též parádní, jen mě na něm štve, že je potřeba vyhradit novému jádru dopředu místo. A za námět k falejmu jednoznačně * THUMBS UP*.

[the.max]

PS: kdyby to někoho zajímalo, tak uptime se samozřejmě vynuluje.

Sakra

[Jirka]

Na produkčním bych to asi nezkoušel. Přijde mi to trochu jako loterie, zvlášť po uvážení těch nedefinovaných stavů zařízení.

[Zopper]

Jelikož bych řekl, že definovaný/nedefinovaný stav záleží na konkrétním typu zařízení a ne na náhodě, můžete si to vyzkoušet na identickém HW a pokud žádné problémy nejsou, tak přesunout za běhu. Ale to je jen moje teorie, pokud se pletu, opravte mě.

[Tutor]

Opensuse už nějakou dobu kexec používá při instalaci systému. Člověk vloží instalační DVD do počítače, nabootuje z něj, spustí instalaci, a skončí se systémem běžícím na HDD - na rozdíl od ostatních instalací OS bez restartu počítače.

[Rovano]

Ještě by mohli opravit kam cpou zavaděč Grub.

[Heron]

Přeskočí se všechny kroky od spuštění počítače až k zavaděči, což zahrnuje inicializaci hardware, dále činnost firmware (na x86 BIOS) a samotný zavaděč (např. GRUB nebo lilo)

Toto bych jako výhodu ani moc neviděl. Jasně, pro vývojáře jádra, který by jinak musel rebootovat 10x denně je to jistě plus. Ale server/stanici si velmi rád po upgrade jádra kompletně restartnu, aby viděl, zda se vše nastartuje jak má.

[Max]

No, v rollup distrech bych tento argument chápal, ale na debianu, nebo centos, to ne. Tam se snad není čeho bát. Všechno je stejné, jen se opraví chybky.
Zdar Max

[Semo]

Pred nejakymi cca 2 rokmi tu niekto pisal do blogu ako mu Windowsy (alebo mozno nejake velke tazkotonazne linuxove distro) nedokazu inicializovat grafiku. Takze to poriesil bootovanim v 2 krokoch, kde najprv sa nahodila nejaka minidistribucia (ktora inicializovala hw spravne), ktora po inicializovani hw spravila kexec na hlavny system. Co je na jednej strane koncept Pat&Mat na druhej strane uzasny trik ako zachranit nb pre vyhodenim do kosa za cenu o par sekund dlhsieho bootu.

[____]

Windows přes kexec asi ne. :)

[David Watzke]

Kexec umí nahrát libovolné jádro, nejen Linux, ale jak to je s Windows, to vážně netuším. Nedokážu si to dost dobře představit

[Grunt]

No, to asi fakt ne. Na druhou stranu Coreboot prej nějak Widle zavádět umí. Nějak GNU NTLDR by se docela hodil.

[Semo]

Nasrali ste ma, tak som to nasiel: http://www.abclinuxu.cz/blog/rm_rf_this_blog/2007/5/framebuffer-gensplash-intel-915-a-sirokouhly-displej. No, nie su to windowsy, nie je to fatalne (takze ani nb do kosa) a dnes je to uz opravene systemovejsie, ale na to, ze to bolo pred 3.5 rokmi, som si to nepamatal az tak zle.

[Grunt]

Nasrali ste ma, tak som to nasiel

Ty jo, tak sme fakt borci. Jinak jsem na to mrknul i já a též to není tak žhavé.

[Gilhad]

te nodkaz mel byt asi takto :)

Framebuffer, gensplash, intel 915 a širokoúhlý displej

[imploder]

Je škoda, že Fedora se zřejmě vydala opačným směrem: nejen že nejde za běhu aktualizovat jádro, ale nejdou aktualizovat ani aplikace. Ve 13 se vždycky před aktualizací kontrolují spuštěné procesy a když je spuštěný nějaký, kterého se týká ta aktualizace, tak se aktualizace zastaví a nepokračuje dál, dokud ten proces neukončím. Zjistit který proces to je (např. thunderbird) a ukončit ho, musím já.

Abych si na to jen nestěžoval: dřív žádná taková kontrola nebyla a pak se stalo, že po tom, co byl firefox za běhu aktualizován, se v něm při poklikání na hvězdičku objevily místo normálních tlačítek jakési čtverečky. I když tyhle případy nejsou časté, stát se to může. Ukončovat aplikaci kvůli aktualizaci je sice otrava, ale po opětovném spuštění je pak jisté, že to běží jak má a ne nějak polovičatě aktualizované (tj. samotný exe se zatím neaktualizoval, ale už načetl nějaké soubory, které už jsou aktualizované - to může vést k poruše). Akorát teda nechat uživatele hádat, co má ukončit, je dost trapné, v tomhle to chce zlepšit.

[michich]

Tuhle kontrolu dělá pouze PackageKit, yum ne.

A netýká se to všech aplikací, ale pouze těch vyjmenovaných v NoUpdateProcessList v /etc/PackageKit/PackageKit.conf. Ve výchozí konfiguraci je tam pouze firefox.

To, že to okno neříká, který proces je potřeba ukončit, je nahlášený bug.