Systemd – úvod a představení System V init

15. 3. 2011 | Michal Vyskočil | Systém | 26190×

Systemd je nejnovější hvězda v tak poklidné a konzervativní oblasti, jako jsou init systémy. V následující sérii článků si probereme jeho vlastnosti, i když dnešní díl půjde zpátky ke kořenům - k System V init.

Obsah

• Na počátku byl (System V) init
• Syntaxe /etc/inittab
• Na pořadí záleží
  • Ostatní unixové systémy
• Alternativy sysvinit
  • initng
  • runit
  • Upstart
• Výhody System V init
• Nevýhody System V init
  • Psaní démonů
  • Psaní init skriptů
  • Paralelní spouštění služeb
  • Spouštění služeb na vyžádání
  • Sledování procesů
  • Doba spouštění
• Závěrem

Na počátku byl (System V) init

Nejprve se pojďme podívat, jak se vlastně dnes zavádí takový typický linuxový systém. Předpokládáme, že používá init systém odvozený z Unix System V, čili sysvinit. Po startu počítače, init ramdisku a jádra je prvním spuštěným procesem /sbin/init. Ten otevře rouru /dev/initctl, která slouží pro komunikaci s démonem, a hlavně zpracuje soubor /etc/inittab.

Zjistí výchozí úroveň běhu

# The default runlevel.
id:2:initdefault:

Jméno skriptu spouštěného pouze jednou na úplném začátku zavádění

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

Co spustit při přechodu na jinou úroveň běhu

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
...

Co dělat při stisku Ctrl Alt Delete

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Definice virtuálních terminálů

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
...

A jiné akce, například reakce na zprávu od systému napájení.

Syntaxe /etc/inittab

Syntaxe záznamů je docela jednoduchá

id:runlevels:action:process

kde id je až čtyřznakový unikátní identifikátor daného záznamu. Nijak nezbytná položka, ale některé prastaré programy mohou očekávat stejné id jako číslo virtuálního terminálu, takže záznam pro tty8 by měl mít id 8.

runlevels - úrovně běhu - definuje, pro které úrovně běhu má být daný řádek vykonáván. Může být uvedena žádná (pro rc.S), jedna, nebo více.

action specifikuje akci, která má být vykonána. Podporované jsou respawn - opětovné spuštění procesu, pokud skončí, wait - spuštěn jednou při vstupu do dané úrovně, init počká na jeho dokončení, once - značí spuštění bez čekání a podobně. Podrobnosti jsou v man 5 inittabs.

process určuje spustitelný soubor, který má být spuštěn.

A to je vše, co sysvinit dělá - spouští procesy na základě zadaných podmínek, kterými mohou být změna úrovně běhu, ukončení procesu (v případě respawn) a podobně. Vlastní logika zavádění je potom povětšinou vtělena do shellových skriptů, typicky v adresáři /etc/init.d.

Na pořadí záleží

Pořadí spouštění init skriptů je důležité - například prakticky jakýkoli démon potřebuje spuštěný syslog, je dobré připojit /usr dříve, než se z něj něco hodlá spustit a podobně.

System V init to řeší adresáři /etc/rc$úroveň.d/, které obsahují symbolické odkazy init skriptů. Jejich jméno odpovídá vzoru

[SK][pořadí]název

První znak S značí, že se má daná služba nastartovat (/etc/init.d/foo start), znak K označuje zabití (/etc/init.d/foo stop). Část pořadí je dvojciferné číslo označující kdy se daný skript spustí. A následuje samotné jméno skriptu, které nenese žádnou informaci, ale trochu zlepšuje čitelnost výpisu adresáře.Tak například S10sysklogd znamená startuj syslogd s pořadím 10, což znamená, že pouze skripty S09xxx a nižší by se spustily před syslogd.

Otázkou je, jak vlastně čísla zjistit? V pradávných dobách, kdy muži byli muži a počet démonů spouštěný na takovém typickém unixovém systému byl nepatrný, stačila statická alokace (podrobnost se statickým /dev není náhodná). V dnešních dobách, kdy muži pravděpodobně vyhynuli a počet démonů narostl (podobnost čistě náhodná), stejně jako závislosti mezi nimi, si se statickou alokací nevystačíme.

Standard LSB definuje hlavičku init skriptu, který obsahuje i systém závislostí. Hlavička má podobu komentáře na začátku každého init skriptu:

### BEGIN INIT INFO
# Provides: foo
# Required-Start:    $syslog $remote_fs
# Required-Stop:     $syslog $remote_fs
# Should-Start:      $named
# Should-Stop:       $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start foo daemons
### END INIT INFO

Příklad hypotetického démona foo, který vyžaduje mít spuštěný syslogd a připojené vzdálené souborové systémy. Což může být i /usr, pokud provozujeme vzdálenou instalaci přes nfs. Jako volitelnou závislost vyžaduje named démona. Pokud totiž není v systému nainstalován syslogd, instalace init skriptu skončí chybou. Pokud chybí named, chyba se nevyvolá a skript se nainstaluje (vytvoří se příslušné odkazy v rc.d adresářích).

Ostatní unixové systémy

Init systém BSD byl koncipován jinak. Hlavní slovo měl jeden velký /etc/rc skript. Výhodou byla jednoduchost a přehlednost, kterou adresáře rc.d System V unixu nemají. Nicméně křehkost tohoto řešení nakonec vedla k rozdělení na jednotlivé init skripty a dokonce byl přidán příkaz rcorder řešící pořadí spouštění. Některé linuxové distribuce (Gentoo, Arch Linux) používají init systém odvozený z BSD.

Alternativy sysvinit

Klasický init systém trpí mnoha problémy. Ve snaze vyřešit alespoň ty, které považovali tvůrci alternativního systému za nejvíce palčivé, bylo vytvořeno mnoho náhrad od initng, přes upstart až po poměrně ezoterický twsinit částečně napsaný v assembleru.

initng

Náhrada klasického systému sysvinit. Hlavním rozdílem je fakt, že tento systém spouští služby paralelně hned, jak jsou splněny jejich závislosti, tudíž zabraňuje zbytečným prodlevám sériového spouštění úloh. Ovšem žádná z hlavních distribucí jej nikdy neadaptovala, ačkoli existuje jako alternativa pro mnoho distribucí.

runit

Další alternativa k sysvinit - podporuje několik unixových platforem, podporuje řešení závislostí. Odstraňuje koncept runlevelů a zavádí pojem stage - první je bootovací fáze (obdoba rc.S), druhá startuje uživatelské procesy a poslední je ukončovací. Existuje jako alternativa pro mnoho distribucí, nicméně podobně jako initng nebylo žádnou významnou adaptováno.

Upstart

Princip fungování systému upstart je zcela odlišný od sysvinit i všech alternativ (které jsou obvykle sysvinit a něco navíc). Hlavní odlišností je systém založený na událostech. Upstart sleduje mnoho událostí - jako spuštění, ukončení procesu, nastavení síťového rozhraní, připojení, odpojení disku a podobně.

Pořadí spouštění je definováno těmito událostmi: pokud se objeví událost syslog-started, spouští se ostatní démoni, kteří potom emitují vlastní události démon-started, na které pak reagují další jednotky.

Mezi další zajímavosti patří deklarativní zápis "init skrptů" a zpětná kompatibilita se skripty sysvinit. Z principu jeho fungování plyne, že dokáže sledovat stav procesu a dokonce by měl umět nahradit i letité unixové služby jako cron. Jako jediná z alternativ se významněji rozšířil i do ostatních distribucí - z mateřského Ubuntu se propracoval přes Fedoru do RHEL 6, do WebOS, Maemo/Moblin/Meego nebo ChromeOS.

Výhody System V init

Zásadní výhoda takového systému je jednoduchost.

Ačkoli zrovna s tím by vývojáři BSD nesouhlasili, tak klasický init je velice jednoduchý - na mém systému má binárka /sbin/init velikost 32 kB. Pro zajímavost /sbin/udevd má 48 kB, /bin/true 12 kB. Navíc, většina logiky init systému je zabudována ve skriptech, protože init systém jako takový reaguje na události výhradně spuštěním nějakého procesu. Právě používání skriptů dává systému netušenou flexibilitu, protože programem je možné vyjádřit více, nežli deklarativním zápisem.

Nevýhody System V init

Psaní démonů

Unixový démon se chová jinak než klasická aplikace, která běží na popředí terminálu a ukončení rodičovského procesu vede k jeho smrti. Naproti tomu démon běží jako by na pozadí a ukončení procesu, který jej spustil, na něj nemá vliv. To značí, že programování démona se musí lišit od klasické aplikace, což vývoj démonu poměrně komplikuje, a proto má většina možnost být spuštěn na popředí - tedy ne v režimu démona, což je velice užitečné pro ladění.

Proč je to nevýhoda sysvinit? Protože nijak nepomáhá psaní takových aplikací a namísto toho spoléhá na to, že autoři budou používat magii jako double-forking a podobně.

Psaní init skriptů

Ačkoli na jedné straně dává používání skriptů celému systému značnou flexibilitu, na straně druhé je právě tento přístup koulí na noze. Init skripty se, jak jejich název napovídá, píší v shellu. Jejich úloha je ve většine případů stejná - zkontrolovat parametr, s ním je skript spuštěn a provést zadanou akci - spuštění, restart, zastavení, či zjistit stav příslušného démona. Rovněž se starají o vytváření pid souborů s PID spuštěného démona a podobně.

Nevýhoda tohto přístupu - duplikace kódu - ačkoli drtivá většina skriptů dělá to stejné, jejich tvorba začíná kopií šablony, do níž se dopíší cesta k binárnímu souboru a jméno a skupina, pod kterou má být démon spuštěn. Tento postup je nepřehledný, náchylný k chybám a navíc jsou skripty pro každou distribuci trošku jiné - pro upstream je prakticky nemožné napsat dobrý init skript.

Paralelní spouštění služeb

Klasický init spouští skripty jeden po druhém. To pochopitelně zjednodušuje celý proces z hlediska implementace, na druhou stranu způsobuje, že systém většinu času čeká. Paralelní spouštění umožňuje využívat systém na maximum a odstraňuje čekání.

Spouštění služeb na vyžádání

Jediným způsobem, kterak v sysvinit spustit službu, je spustit příslušný init skript. Služba se spouští, přestože v danou chvíli neexistuje žádost, kterou by mohla zpracovat. Jako řešení tohoto problému byl vytvořen démon (x)inetd, který dokáže spouštět služby až v okamžiku, kdy existuje žádost o její použití.

Sledování procesů

Přestože samotný init umí sledovat procesy, dělá to pouze u procesů z /etc/inittab. Ovšem dobrý init systém by měl umět reagovat i na jednotlivé služby a v nejlepším případě i na události v systému.

Doba spouštění

V dávných dobách, kdy unixové stroje byly výhradně dlouhodobě běžící servery, častokrát zazdívané při stavebních úpravách do zdí, nebyla doba spouštění nijak významným parametrem. V současné době, kdy se distribuce Linuxu objevují na všem od Top500 serverů, přes chytré telefony až po běžné desktopy, je doba startu takové distribuce parametrem významným.

Většina zrychlování doby zavádění implementuje paralelní spouštění, někde se nahrazuje /bin/bash za odlehčenější dash, jinde dokonce mají deklarativní syntaxi a většinou se uživatelům doporučuje vypínat služby, které nezbytně nepotřebuje.

Přestože určitá část komunity zůstává k podobným snahám skeptická a poukazují buď na fakt, že doba startu je zlomkem doby strávené samotnou prací, či na rychlost probouzení po uspávání, skutečností je, že doba startu je významným generátorem blogpostů, článků na Phoronixu, Twitter zpráv a podobně. A typickou první otázkou u každého nového init systému je - o kolik startuje systém rychleji než se sysvinit.

Závěrem

V tomto článku jsme si rozebrali klasický sysvinit, jak funguje, co je /etc/inittab. Také známe jeho výhody, nevýhody, populární (linuxové, jinak by sem patřil i launchd a SMF pro Solaris) alternativy k němu, a taky fakt, že lidé zbožňují měření čísel a jejich následné porovnávání, a to v libovolné oblasti.

V příští části si představíme myšlenky Lennarta Poetteringa, autora démona systemd. Dozvíme se o tom, proč paralelní spouštění služeb nefunguje a co všechno by měl ideální init démon umět.

       

Komentáře

[Petr Bravenec]

Gentoo je založené na BSD init? Bez ironie či jiných postranních úmyslů - to je pro mě zajímavá novinka. Začal jsem na SVR (sysvinit), pak Slackware (bsd), RedHat (sysvinit) a nakonec Gentoo. To se nepodobá ničemu jinému výše uvedenému. Už párkrát jsem uvažoval, odkud se systém v Gentoo vzal. Mně osobně totiž systém v Gentoo připadá velmi snadný a přehledný.

[petr_p]

System V init je jenom /sbin/init, který projde /etc/inittab a podle jeho obsahu spustí skripty (případně je znovu nastartuje, když umřou). Tím veškerá práce initu končí (vyjma sledování signálů nebo /dev/initctl).

Dále popisovaný systém skriptů v /etc/init.d/* a /etc/rc* s jejich krkolomným pojmenováním je již čistě linuxová konvence. Init se o tohle vůbec nezajímá.

V Gentoo, mám dojem, je stále výchozí System V init, pouze systém skriptů a jejich konfigurace jsou inspirovány (Free?)BSD. Ostatně si stačí vypsat soubory, které sys-apps/sysvinit vlastní.

Nicméně Gentoo s novým sys-apps/baselayout-2 směřuje k jinému systému OpenRC, který je skutečně vyvíjen a používán i na FreeBSD a NetBSD a který nabízí interpreter vlastních init skriptů /sbin/runscript, nabízí řízení podle událostí (například připojení síťového zařízení) a tak dále.

Jednotlivé úkoly jsou ale stále odděleny od /sbin/init (35 040 B na x86), takže když se něco rozbije, tak se jedná jen o omezenou oblast, kterou je snadno možné najít. To se bohužel nedá říci o SystemD, který se snaží řešit vše na jednom místě, ale nic z toho (zatím) nedělá pořádně.

[kmarty]

Dále popisovaný systém skriptů v /etc/init.d/* a /etc/rc* s jejich krkolomným pojmenováním je již čistě linuxová konvence. Init se o tohle vůbec nezajímá.

Na to ze ma jit o ciste linuxovou konveci je zvlastni ze se s tim clovek setkava i u Solarisu, resp. SunOSu, ktery ma klasicky SysV init a nerekl bych ze kopiroval od Linuxu.

[petr_p]

Dobrá, tak si odmyslete přívlastek „linuxová“, zřejmě to vymysleli už na System V (nebo dřív). Nicméně součást initu to není. To by totiž muselo existovat rozhraní mezi initem a init skripty.

[Petr Bravenec]

Dále popisovaný systém skriptů v /etc/init.d/* a /etc/rc* s jejich krkolomným pojmenováním je již čistě linuxová konvence. Init se o tohle vůbec nezajímá.

Tohle zcela určitě linuxová konvence není. S tímto jsem se setkával už na SVR před dvaceti lety.

[Zdenek]

Tak, tak. /etc/init.d/ skutecne pochazi z SysV.

[Michal Vyskočil]

Gentoo je založené na BSD init? Bez ironie či jiných postranních úmyslů.

No měl jsem zmínit, že se jedná spíše o layout skriptů a adresářů, který je systémem BSD inspirován.

[iki]

Běžné programy jdou snadnou spouštět jako démoni pod supervisorem, vč. monitoringu a python API.

[trekker.dk]

podporuje řešení závislostí

Šlo by othle nějak rozvést? Pokud vím, tak jediná podpora závislostí, kterou má runit, je "spouštěcí skript služby si sám zkontroluje, jestli jsou všechny závislosti dostupné"

[Michal Vyskočil]

Nijak podrobně jsem závislosti v runit nezkoumal.

[trekker.dk]

Jo, web na tom odkazu znám - nicméně tam se píše to, co jsem zmínil vejš, tj. závislosti "vyřeš si sám"

[Michal Vyskočil]

Aha, tak jak to tak teď čtu, tak tam mělo být nepodporuje závislosti - mě zmátla ta první věta, která vyznívá, že je runit nějak řeší sám.

[Andrej]

U alternativ naprosto chybí jakákoliv zmínka o SMF.

[Hue]

...Také známe jeho výhody, nevýhody, populární (linuxové, jinak by sem patřil i launchd a SMF pro Solaris) alternativy k němu...

[herne the hunter]

pokud by někoho nebavilo čekání na další část článku, tak tady si může poslechnout přednášku o systemd přímo od jeho autora…

[mimi.vx]

<rejp> žádného démona neznám , vale jen "daemony" </rejp>

[Jakub Lucký]

<politicalcorrectness>myslíš spiritual guide?</politicalcorrectness>

[Michal Vyskočil]

Slovo daemon je v češtině zlá, nepěkná věc - asi jako hockey, nebo kopaný míč.

[pakanek]

Chybka: (podrobnost se statickým /dev není náhodná)