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

2. 11. 2010 | David Watzke

Články - Kexec – výměna jádra bez restartu  

kexec je systémové volání, které umožňuje aktualizovat Linux kernel za běhu, tedy bez potřeby restartu počítače. Minimalizuje se tím odstávka stroje potřebná k aktualizaci jádra. V tomto článku si povíme něco z málo teorie a ukážeme si jak na to prakticky.

Obsah

• Proč (ne)?
• kexec v jádře
• Nástroje kexec-tools
• Shrnutí, osobní zkušenosti a závěr

Proč (ne)?

Aktualizace jádra bez restartu počítače zní dobře. Jak je to vlastně možné? Jelikož je obraz jádra uložen na fixním bodě v paměti, není až takový problém jej přepsat obrazem jiným. To se dělá ve třech krocích: nejdřív se obraz nahraje do paměti uživatelského prostoru, potom se přesune do dynamické paměti jádra, zkopíruje se na místo jádra původního a načte se.

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). Z tohoto kromě zřejmé výhody, že se ušetří nějaký čas, mimo jiné také vyplývá, že je zde riziko toho, že se některé zařízení bude po načtení nového jádra nacházet v nedefinovaném stavu.

Použití kexec přináší jednu zajímavou výhodu, kterou ocení hlavně vývojáři jádra. Jde o to, že po jeho zavolání se zachová obsah RAM a díky tomu je možné zjistit např. proč došlo k nějaké chybě v aktuálně načteném jádře. Nemusíte se spoléhat například na rozbitý ovladač disku, protože můžete nahrát nové jádro, kde je ovladač v pořádku a uložit na disk obraz paměti pomocí něj.

Je zde ovšem i další nevýhoda. Kexec se nestará o ukončování uživatelských procesů, odpojování disků, atd. To vše musíte udělat sami.

kexec v jádře

Kexec není prvním projektem, který se o něco takového snaží. Předcházely mu projekty bootimage a Two Kernel Monte (v dobách Linuxu 2.3/2.4). Kexec je dostupný v Linuxu až od verze 2.6. Dříve jej Eric W. Biederman vyvíjel jako patch pro Linux 2.5, který podporoval pouze 32-bitovou architekturu x86, ale později se dostal do oficiálního (vanilla) jádra a získal podporu dalších architektur (x86-64, PPC, IA64, ARM, MIPS). Nyní, když chcete podporu kexec v jádře (což je samozřejmě nutné, pro použití kexec), musíte povolit volbu CONFIG_KEXEC.

Nástroje kexec-tools

Aby bylo možné kexec ovládat z uživatelského prostoru, musí pro to existovat nějaký nástroj. Balíček kexec-tools obsahuje potřebný program kexec (a kdump, kterým se nebudu zabývat), se kterým je třeba pochopitelně pracovat s rootovskými právy.

Nejdříve předáme přepínači -l cestu k novému obrazu jádra, potom pomocí --append= přidáme případné argumenty jádru (nezapomeneme předat kořenový adresář pomocí "root=...") a případně ještě počáteční ramdisk initrd pomocí --initrd=. Příkaz nakonec může vypadat takto:

kexec -l "/boot/vmlinuz26" --append="root=/dev/sda2 ro" --initrd="/boot/kernel26.img"

Tímto se jádro zatím pouze načte na dočasné místo v paměti. Nyní je čas povypínat běžící procesy (můžete použít initskripty, případně kill na ty neposlušné), odpojit oddíly a změnit připojení kořenového adresáře pouze pro čtení, což se dělá takto:

mount -o ro,remount /

Nyní je čas zahájit spuštění nového jádra, což se provádí příkazem:

kexec -e

kexec má ještě několik přepínačů, z nichž jsou pro běžného smrtelníka zajímavé například tyto: -u zruší načtení kernelu pomocí -l, --reuse-cmdline použije jako argumenty běžícího jádra pro nové jádro, --reuseinitrd použije ramdisk z prvního bootu a --reset-vga se pokusí resetovat standardní VGA zařízení. Ne všechny přepínače jsou dostupné pro všechny případy, proto si případně přečtěte manuál (man kexec).

Shrnutí, osobní zkušenosti a závěr

Když shrneme výhody a nevýhody, dojdeme k tomuto:

+ kratší odstávka při změně jádra
+ zachování dat v operační paměti (vhodné hlavně pro vývojáře)

- uživatel se musí postarat o řádné ukončení procesů a odpojení oddílů disků (*)
- tím, že nedojde k reinicializaci hardwaru, se může stát, že se nějaké zařízení bude po spuštění nového jádra nacházet v nedefinovaném stavu

Je na každém, aby se rozhodnul, jestli mu několik ušetřených sekund stojí za tato rizika.

Ještě se vrátím k hvězdičce (*) u první nevýhody, kterou jsem zde uvedl. Jelikož píši článek o kexec, bylo by asi zvláštní, kdybych jej nevyzkoušel. Vrhnul jsem se tedy na to, postupoval jsem jak jsem měl a když jsem došel k volání kexec -e, způsobilo paniku jádra (soudě dle blikajícího numlocku). Ve wiki Arch Linuxu, který používám, jsem se dočetl jaký je podporovaný postup na této distribuci a byl jsem mile překvapen. Initskripty Arch Linuxu s použitím kexec totiž počítají a spustíte-li:

/etc/rc.d/kexec start
/etc/rc.d/kexec load
reboot

systém se postará o zbytek sám. První příkaz povolí použití kexec, když spustíte klasický příkaz reboot (nebo prostě restartujete počítač z grafického prostředí). Druhý příkaz načte nové jádro, které má být spuštěno místo současného (nastavení čte z konfiguračního souboru /etc/conf.d/kexec). Třetí příkaz je v tomto případě již jen jedním ze způsobů, jak proces spuštění nového jádra zahájit.

Rozhodnete-li se kexec používat, nejdříve si tedy zjistěte preferovaný postup na vaší distribuci, pravděpodobně totiž bude uživatelsky podstatně přívětivější. Pro příklad uvedu ještě relevantní odkaz na Gentoo wiki.

Diskuse k tomuto článku

[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.