Jak pracuje klasický init
Init je „první systémový proces”. To znamená, že je spouštěn bezprostředně po startu jádra a má na starosti spouštění systému, zastavení systému a správu veškerých interních procesů. On se stará o zavedení příslušných služeb, nastavení sítě, aktivaci hardware a podobně.
Aktuálně používaná implementace init vychází ze systému UNIX System V a je proto známá jako sysvinit. Tento klasický init vytváří systém úrovní běhu (runlevelů), které jsou obvykle označeny číslem. V případě změny úrovně je spuštěna příslušná sada skriptů. Rovněž při ukončování úrovně je spuštěná jiná sada, která se postará o správné zastavení služeb. Tolik stručná rekapitulace, a pokud vás zajímají podrobnosti, můžete je najít například v jednom z našich starších článků.
Tento způsob správy systému samozřejmě funguje už několik desítek let a zřejmě by fungoval i dále. Problém je, že z dnešního pohledu už přináší řadu omezení. Není tedy divu, že se řada vývojářů snaží najít nový způsob.
Proč init nestačí?
Statické zavádění konkrétní skupiny skriptů a aplikací funguje velmi dobře, pokud jste schopni zajistit dodržení všech závislostí. Ano, i startovací skripty je potřeba spouštět v konkrétním pořadí. Pokud například chceme inicializovat síťové služby, musíme předem zajistit získání IP adresy od DHCP serveru. Stejně tak například před spuštěním hudebního démona musíme nejprve aktivovat ALSA a podobně.
Potíž je v tom, že řada aktuálně prováděných akcí už není „dostatečně předvídatelná” na to, abychom byli schopni předem říci, co je třeba zavést. Paradoxně tak problém zhoršují moderní jádra řady 2.6, která nabízejí hotplug funkce, umožňující přidávat a odebírat zařízení během práce. Během startu systému tedy nemáme jistotu, že je hardware připojen a my můžeme zavádět příslušný software.
Situací, kdy dochází ke změnám důležitých systémových součástí, je dnes poměrně hodně. Konkrétně se může jednat o odpojení/připojení nějakého hardware, uspání systému, snaha připojit některé souborové systémy a podobně.
Dobrým příkladem jsou například USB disky, se kterými nemůžeme na počátku nijak počítat, protože nejsou jednoduše k dispozici. Zavedení příslušných ovladačů, zapsání do /etc/fstab a připojení tedy můžeme provádět až ve chvíli, kdy je disk zapojen.
Podobný problém přichází například v případě adresáře /usr. Pokud se během práce pokusíme takový disk přidat, je potřeba detekovat síťové zařízení, nahrát do něj firmware, zapojit třeba bezpečnostní vrstvy, zavést NFS a pak teprve můžeme připojovat adresář.
V takovém případě je potřeba hlídat mnoho různých závislostí, volat sekundární skripty, zavádět nové jaderné moduly a podobně. Je tu samozřejmě možnost upravit sysvinit skripty tak, aby se dokázaly s většinou událostí vypořádat. Je to ale jednak velmi komplikované, zároveň to může přinést další problémy a stejně tím nevyřešíme veškeré problémy. Většina systémů to tímto způsobem samozřejmě řeší.
Je tu Upstart
Upstart je náhradou za klasický init, kterou napsal Scott James Remnant. Jeho zaměstnavatelem je společnost Canonical, je tedy logické, že je Upstart psán primárně pro distribuci Ubuntu. Je samozřejmě použitelný v dalších systémech.
Upstart přistupuje ke správě systémových služeb naprosto jinak než sysvinit. Jeho práce je velmi dynamická a především naprosto asynchronní. Znamená to, že je schopen správně a efektivně zavádět připravené služby, aniž by k tomu potřeboval předem napsaný seznam a postup.
I přesto se ovšem snaží zachovat plnou zpětnou kompatibilitu. To je obecně považováno za jeho velkou přednost. Samozřejmě není jediným projektem, který se snaží o náhradu sysvinit. Ostatní podobné snahy ovšem vyžadují naprosté přepsání startovacích skriptů a nedovolují použití těch starých, případně kombinaci obou přístupů. To Upstart umí, takže jeho nasazení není pro systém tak kritické a průlomové jako v případě jiných náhrad init.
Co umí?
Řekli jsme si, že Upstart nejde tradiční cestou startovacích skriptů, ve kterých jsou pevně stanoveny jednotlivé kroky pro start systému. Upstart místo toho zavádí systém samostatných akcí (jobs). Akce nejsou vyvolávány automaticky, ale na základě vyvolaných událostí. Každá událost může způsobit spuštění dalších akcí, a tak dále.
Výhodou tohoto asynchronního přístupu je také zrychlení startu systému, protože jednotlivé akce se mohou spouštět paralelně na pozadí. Samozřejmě není například důvod, proč by se při čekání na DHCP server (při inicializaci sítě) nemohla třeba inicializovat zvuková karta nebo spouštět logovací démon.
Díky flexibilitě Upstart je možno také zjednodušit systémovou konfiguraci. Protože je možno přesně nastavit, který proces se má kdy a jak spouštět, odpadá nutnost provozovat v systému doplňkové démony jako je například cron, inetd, acpid, apmd a podobně. Tito démoni v principu spouštějí akce ve chvílích, kdy je to třeba. Což je přesně činnost, na kterou je Upstart připraven.
Kde Upstart najdeme?
Už jsem se zmínil o nasazení v Ubuntu. Canonical svůj Upstart do standardní instalace integroval už v Edgy Eft, ale až ve Feisty Fawn získal na důležitosti. Další distribucí, ve které Upstart najdeme, je Frugalware Linux.
Jak Upstart pracuje?
Tolik k teorii zavádění a správy systému. Velmi zajímavá je také vnitřní činnost a princip Upstart. O tom, jak to celé funguje, jak se předávají události a které akce je možno takto spravovat, si povíme ve druhé části tohoto článku.
