Systemd – vlastnosti a schopnosti

23. 3. 2011 | Michal Vyskočil | Systém | 20280×

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. Dnešní díl bude o přístupu systemd k problematice a vlastnostech celého systému.

Obsah

• Rethinking PID 1
  • Skutečně paralelní start démonů
  • Odložené spuštění
  • Paralelní souborové operace
  • Deklarativní popis init skriptů
  • Sledování procesů
  • Ovládání prostředků
  • Ostatní vlastnosti
• Status update
• Závěrem

Rethinking PID 1

Koncem dubna 2010 Lennart Poettering (možná znáte jeho ostatní projekty – PulseAudio a Avahi) napsal blog Rethinking PID 1. V něm oznámil vznik svého projektu systemd, který mění způsob nazírání na init, čili procesu s PID 1.

Jako hlavní znak dobrého systému Lennart uvádí rychlý start, což je poněkud nešťastné, protože odvádí pozornost od inovativního návrhu a způsobu fungování. Ale budiž.

Skutečně paralelní start démonů

Problém paralelizace řeší prakticky každá alternativa, nicméně v praxi to pak dopadá následovně – chceme spustit libvirtd a X11. Oba nicméně potřebují (potřebovali) HAL, který ovšem potřebuje D-BUS démona, který potřebuje spuštěný syslogd. Celé to obrovské úsilí o paralelizaci skončilo tím, že první tři služby se zavádějí postupně a teprve poslední dvě vedle sebe.

Ve snaze odstranit tyto sériové závislosti se systemd dívá na problematiku jinak. Co je skutečně potřeba pro sériové spouštění démonů? Klasické unixové démony obvykle vyžadují přítomnost služby poskytované jiným démonem, což je typicky AF_UNIX socket někde v souborovém systému. Ale může to být i AF_INET, anebo speciální zařízení. Takže třeba D-BUS klient potřebuje unix socket /var/run/dbus/system_bus_socket, k němuž by se mohl připojit a démon zapisující do systémového logu zase očekává socket /dev/log.

Takže, pokud se podaří tyto sockety vytvořit dříve, můžeme oba dva démony jednoduše spustit současně, ačkoli jsou jejich závislosti sériové. Naštěstí v unixových systémech je to prosté – můžeme vytvořit socket před startem vlastního démona a potom mu jej předat prostřednictvím volání exec(). V případě, že nějaký jiný démon potřebuje s takovým socketem pracovat, pak je prostě přidán do fronty požadavků a pozastaven do doby, než se spustí démon, který takové požadavky akceptuje.

Díky tomu systemd nevyžaduje explicitní uvádění závislostí. Celá tato mašinérie jednoduše využívá existující kód v jádře a jako vedlejší efekt nabízí opravdu masivně paralelní start všech služeb.

Odložené spuštění

Alternativní a prakticky nevyužívaná strategie pro zkrácení doby startu je odložení doby startu démona až na doby, kdy bude existovat první požadavek na její spuštění. Tento přístup byl implementován desítky let jako démon (x)inetd, ale jako samotný init systém se neujal.

V praxi existuje mnoho případů, kdy není nezbytné startovat služby při startu. Tiskový démon cups není nezbytné spustit dříve, než přijde první požadavek na tisk. Bluetoothd není třeba, pokud neexistuje potřeba komunikovat přes bluetooth, avahi není nutné, když není systém připojen k síti a dokonce ani ssh démona nemusíme spouštět, pokud se na něj zrovna nechce někdo připojit.

Princip, na kterém systemd provádí masivní paralelní start, lze jednoduše použít i pro spouštění na požádání – kdykoli systemd detekuje, že někdo chce použít daný socket, automaticky nastartuje patřičnou službu. Tím jsou splněny dva předpoklady rychlého startu – spouštět služby co nejvíce paralelně a rovněž spouštět pouze ty, které jsou skutečně potřeba. Mimochodem, stejně tak funguje i launchd systému OS X, který byl, jak Lennart uznává, zdrojem inspirace pro systemd.

Stejná logika jde aplikovat i na moderní desktopové démony jako Avahi, bluetoothd a podobně, které namísto socketu komunikují přes D-BUS. Jeho obslužný démon totiž umí aktivovat služby na požádání – tedy spustit obslužného démona až v okamžiku, kdy je proveden první požadavek na jeho rozhraní. Stejně jako v případě socketů jsou dotazy řazeny do fronty a zpracovány v okamžiku, kdy obslužný démon naběhne.

Čili tento přístup umožňuje se nejenom vyhnout zbytečným explicitním závislostem, serializaci při startu – navíc implicitně dokáže spouštět služby na požádání. Slovy Lennarta:

And if that's not great, then I don't know what is great!

A pokud to není skvělé, pak už nevím, co je skvělé!

Paralelní souborové operace

Samotné spouštění démonů je pouze část zavádění, která neběží paralelně a kde se čeká na doběhnutí jedné úlohy po druhé. Nejčastěji jde o souborové operace jako připojování disků, jejich kontrola a kontrola kvót. Teprve po této, často zdlouhavé operaci, se pokračuje v samotném zavádění.

Stejně jako v případě socketů a D-BUS, nástroje pro vyřešení takového problému dávno existují. Jak Lennart píše ve svém blogu, tak Harald Hoyer přišel s řešením v podobě autofs. Nahradit skutečné přípojné body (mount points) systémem autofs a potom jednoduše čekat až nějaká aplikace zavolá open() na daný prostor, čímž se její běh přeruší a požadavek opět umístí do fronty, systém mezitím provede kontrolu integrity i uživatelských kvót, přípojný bod nahradí skutečným a probudí doposud zablokovanou aplikaci. Systém autofs navíc dokáže zpět propagovat chyby, pokud nemohl být daný systém z nějakého důvodu připojen. Pochopitelně takové odložené připojení nemá smysl pro kořenový adresář, nebo pseudosystémy jako procfs a sysfs.

Deklarativní popis init skriptů

Skriptovací init skripty jsou rychlé a pomalé zároveň. Je rychlé je napsat, ale jsou velice pomalé ke spouštění. V zásadě nezáleží na tom, zda používáme těžkotonážní /bin/bash, nebo odlehčenou alternativu, zavádění bude vždy pomalé. Lennart uvádí, že na jeho systému zavádění systému znamená 77 volání grep, 92 volání awk, 23 cut a 74 sed. Což znamená pro každý takový příkaz opakování fork/exec, nahrání dynamických knihoven, kontrolu lokalizace, parsování argumentů příkazové řádky a podobně. Navíc jsou init skripty velice křehké, citlivé na odchylky v nastaveném prostředí a podobně.

Poměrně zajímavou metrikou toho, kolik procesů muselo naběhnout jenom pro zavádění systému je nabootovat, přihlásit se a v terminálu napsat echo $$ pro zjištění PID aktuálního shellu. Lennart uvádí Linux: 1823, OS X 154.

Naštěstí velká část logiky init skriptů se opakuje, takže může být snadno reimplementovaná v C a poskytována samotným systemd. Systemd nabízí deklarativní popis init skriptu, který je snadné napsat, množství výplňového kódu a počet chyb je redukován. Navíc, nejde o nijak nový princip, (x)inetd obsahují právě takový deklarativní způsob psaní služeb. Pro případy, kdy je logika spouštění příliš složitá na deklarativní popis je možné se v něm odkázat na skript, který dané spuštění vykoná.

Jako vedlejší efekt – protože se o spuštění démona stará přímo systemd a ne nějaký shellový kód, není potřeba používat triky jako double-fork pro vyvázání se z aktuálního terminálu. Když už nic, tak procesy spuštěné systemd mají jako rodiče přímo PID 1. Dobrý démon pro systemd má pouze obslužnou smyčku, loguje do stderr a nepoužívá magii, takže v konečném důsledku vypadá více jako běžná aplikace, kterou je snadné ladit.

Ačkoli jsme už na konci našeho původního seznamu, Lennart jde ještě dál a přidává další důležitou vlastnost pro dobrý init systém.

Sledování procesů

Dobrý systém spouštějící služby je také musí umět sledovat. Restartovat, pokud spadnou a sesbírat užitečné informace získané z pádu, poskytnout je systému pro práci s core soubory a zapsat zprávu do systémového logu.

Také musí být schopen kompletně vypnout danou službu, což nemusí být zcela jednoduché. V unixu stačí udělat dvojitý fork a tím se dostat z dosahu kontroly rodičovského procesu, což je mimochodem přesně způsob, jak pracují démoni. Takže splašený cgi skript nemusí být ukončen prostým ukončením Apache.

Naštěstí kernel obsahuje potřebnou technologii – Control Groups, která byla do jádra přidána pro potřeby kontejnerů a nastavování limitů pro jaderné prostředky pro určité skupiny procesů, na rozdíl od tradičního setrlimit vázaného na proces. Výhodou je, že neprivilegované procesy se ze své kontrolní skupiny nemohou dostat. Tím je pro systemd velice snadné procesy kontrolovat. Pro každý proces je jeho skupina viditelná v /proc/$PID/cgroup a navíc jsou skupiny procesů dostupné v sysfs.

Ovládání prostředků

A v neposlední řadě, pokud už init systém dokáže procesy sledovat, mohl by umět i kontrolovat jejich prostředí. Klasické init skripty se obvykle omezují na omezení v podobě uživatele a skupiny, vzácně pak nastavují limity přes ulimit/setrlimit. Schopnosti Linuxu, jak nastavit prostředky, jsou mnohem větší – je možné nastavit plánovač procesoru nebo IO, capability bounding set, CPU affinity a podobně.

Například spouštění updateb s IOPRIO_CLASS_IDLE bude mít pozitivní důsledky na interaktivitu systému, protože požadavky tohoto procesu se začnou vykonávat pouze v případě, že neexistují jiné.

Ostatní vlastnosti

• Kompatibilní /dev/initctl, které poskytuje očekávané rozhraní pro shutdown, poweroff a ostatní podobné příkazy.

• Kompatibilní s utmp a wtmp, přestože je autor označuje za „crufty“, příkazy jako who budou pracovat i se systemd.

• Podpora pro restart procesu init. Stav démonu je před ukončením serializován a poté obnoven. Tímto způsobem jsou podporovány mimo jiné updaty démona bez nutnosti restartu. I v průběhu restartu jsou všechny sockety a jiné zdroje dostupné, takže klienti nezjistí, že se init systém restartoval. Navíc kód pro restart démona je prakticky totožný s kódem pro znovu nahrání konfigurace.

• Transakční systém – při požadavku na start jednotky se nejprve vyhodnotí závislosti, provede se detekce případných cyklů a jejich vyřešení odstraněním volitelných závislostí a pokud vše proběhne v pořádku, přidá se požadavek na spuštění jednotek do fronty požadavků.

• C implementace rozličných služeb vykonávaných v průběhu zavádění jako připojení /sys a /proc, nastavení hostname, nebo síťového rozhraní lo.

Status update

S tím, jak je systemd navržen a funguje, je jasné, že existuje spousta míst, kde se jeho funkce překrývá s funkcí jiné služby. A také to, že existuje spousta nových vlastností, které nebyly v původním článku zmíněny, nebo prostě byly přidány až později, anebo byly zmíněny, ale nedokončeny. Proto vydal Lennart (zatím) dva články s názvem Status Update, kde ukazuje změny, které se v mezičase udály.

• Další speciální služby – .timer pro časové spouštění ve stylu cron. Služba .swap, která připojuje oddíly a soubory pro swap na požádání. A .path pro aktivaci služeb závislých na existenci/vytvoření nějakého adresáře, či souboru.

• Podpora pro značky SELinux, auditd a TCP wrappery. Nástroj systemd-cgl pro vykreslování stromu procesů. Kód, který automaticky zavolá getty nad sériovým portem, pokud je jaderná konzole přesměrovaná na sériové rozhraní. Spousta patchů v nejrůznějších upstream projektech pro podporu socketové aktivace a přidávání .service souborů. Podpora nejrůznějších jaderných virtuálních souborových systémů prostřednictvím autofs – po prvním požadavku na čtení z dané části je nahrán specifický modul a systém připojen.

• Integrace s PAM, takže systemd při spuštění služby pod jiným uživatelem vytvoří a ukončí běžnou pam session. Speciální PAM modul systemd přiřazuje procesy každé takové session do vlastní control group, takže všechny takové procesy jsou (respektive mohou být) po odhlášení ukončeny, bez ohledu na to, zda se nejmenují třeba screen.

• Integrace s dbusd, takže všechny požadavky na aktivaci služeb jsou předávány systemd. Díky tomu lze aplikovat všechna možná nastavení prostředí, která systemd umožňuje. Spolu s tím bylo plně dokončeno D-BUS rozhraní samotného systemd.

• Systemd vytváří /dev/log ihned po startu a propojuje jej s kernel log buffer (kmsg). Hned po startu skutečného syslogd je /dev/log přesměrován na tohoto démona. Protože syslogd po svém startu jako první věc zapíše kmsg do souboru, neztratí se ani jedna zpráva. Navíc, pokud dojde k pádu logovacího démona, /dev/log je opět přesměrován do jaderného bufferu. A v neposlední řadě – systémy, které negenerují spousty událostí (typicky embeded), mohou syslogd úplně vynechat a mít vše ukládané v jaderném bufferu zpráv.

• systemd obsahuje minimální implementaci readahead založenou na fanotify(), fadvise() a mincore(). Podporuje jak SSD, tak klasické rotující disky. Výkonový zisk pro rychle startující systémy je malý, ale změnu pocítí především uživatelé těch starších a pomalejších.

• Inicializace systémových locales přímo systemd.

• Nativní podpora pro /etc/crypttab, která umožňuje připojovat disky LUKS/dm-crypt jak při startu, tak v průběhu života systému. Podpora různých klientů pro zjišťování hesel – buď přes konzoli nebo Plymouth dialog nebo v grafickém prostředí pomocí wall či Gnome agenta.

Závěrem

Důvodem, proč je systemd současná „hvězda“ init systémů, je fakt, že se nejedná pouze o yet another sysvinit alternative. Vlastnosti jako socket/path based aktivace služeb, kontrola prostředí a integrace se spoustou dalších technologií, supervize procesů, které systemd nabízí, jsou alespoň v linuxovém světě jedinečné.

Lennart dále uvádí, že stejně jako launchd, může systemd nahradit současné aplikace pro správu uživatelských relací, jako gnome-session nebo kdeinit. Kontrola stavu procesů, paralelní spouštění a schopnost ukládat aktuální stav a zase jej obnovit – to vše mají oba typy programů společné.

V dalším díle se podíváme systemd na zoubek o něco více.

       

Komentáře

[Xerces]

Díky za článek, slyšel jsem o tom ale zatim neměl čas hledat relevantní informace. Nápady pěkný ale doufám, že se to neprosadí. Příjde mi to dost těžkotonážní. Jsem sám, nebo to taky někomu připomíná runit od DJB? Ano oproti runitu to má daleko více možností. Runit tuším spoléhá na to že služba selže a opakovaně ji zkouší nahazovat čímž trošku "plýtvá" ale paměťová nenáročnost a jednoduchý princip si myslím hovoří proti systemd.

[Jan Molič]

Runit je fajn (mám na mysli Runit Gerry Papeho, to jest přepracováné původní daemontools od DJB). Teprve v praxi se ukazují nedostatky. Samozřejmě v porovnání s klasickým initem SysV u mne vítězí na celé čáře, ale z dnešního pohledu existují lepší inity (například OpenRC).

Runit nemá žádný systém závislostí; ve stylu DJB dělá jen to, co má dělat - inicializaci systému. Vše se spouští paralelně naráz, a tak ho nelze použít pro nízkoúrovňovou inicializaci ve smyslu fsck disků, apod. Snažil jsem se sice svého času vytvořit jakousi nadstavbu, ale vnesl jsem do toho akorát složitost.

Největším problémem, s nímž se člověk u daemontools/runitem setká, je vytuhnutí služby kvůli nefunkčnímu loggeru. Vzhledem k tomu, že služba může pomocí provázání svého stderroru logovat přímo do logger daemona, tak jeho nefunkčnost způsobí zatuhnutí služby. Jde o to, že rouru (stderr), do níž služba posílá hlášky, logger nečte a nakonec se roura zaplní - služba, tj. zapisovatel, vytuhne. Bohužel se stává, že nějaká služba produkuje málo hlášek na stderr, takže zaplnění roury může trvat klidně měsíc - a vy pak nechápete, proč to z ničeho nic přestalo jít... Logovací daemon přitom nenastartuje kvůli tak banální věci, jako třeba špatným právům cílového adresáře. Samozřejmě je možné sledovat funkční loggery skriptem, ale už je to zase nějaká složitost navíc.

Filozofie DJB je skvělá, v praxi však plodí složitost. Nejjednodušší funkce totiž obvykle nestačí a je potřeba je dodat externě a nestandardně (což je ona složitost). Přesto DJB uznávám. Je sice extremista, ale všem ukázal, že atomizovaný Qmail je lepší než molochoidní Sendmail. Střední cestou mezi atomizací a molochem je pluginová architektura. Proto osobně dávám přednost Postfixu před Qmailem, OpenRC před Runitem. Je otázkou, zda systemd je moloch, či se poučil od DJB a činnosti separoval (alespoň interně).

[petr_p]

vytuhnutí služby kvůli nefunkčnímu loggeru

To mi povídejte. Dneska jsem aktualizoval Fedoru-16 a když yum nainstaloval první balíček, tak se zasekl. Tak jsem ho zabil a znovu. Ukázalo se, že se zablokoval v send(2) nad socketem /dev/logger. V tu ránu se nedalo přihlásit přes SSH, nešlo udělat su, dokonce systemctl (nástroj pro ovládání systemd) dokázal rsyslogd zabít až na po páté. rsyslogd mezi tím spal v pthread_cond_wait(), takže se neobtěžoval číst protokol.

[Xerces]

Díky za názor. Na OpenRC se podívám, nějak mne minul.

[ext3fs]

Zajimalo by mne jak tato a podobne aplikace provadi nasledujici veci:

1/ jak rozpoznaji pad procesu od ukonceni (kdyz nejsou rodicovsky proces)

2/ odkud sbiraji informace o procesech mimo z /proc/PID/

Je mozne tohle resit i ciste v userspace?

[rADOn]

1/ Pad poznaji tak ze proces skonci. Ukonceni poznaji tak ze jsou pozadani aby proces ukoncili. sysv init to dela stejne.

[ext3fs]

Ale co kdyz proces neni ukoncen radnou cestou ale spadne? Treba na nedostatek pameti. Jak vi, ze jej maji znovu startovat?

[Karel Zak]

1/ prave pouziva cgroups kde pokud je skupina prazna tak se zavola release_agent

   $ cat /sys/fs/cgroup/systemd/release_agent
   $ cat /sys/fs/cgroup/systemd/systemd-1/*.service/notify_on_release

2/ /proc a /sys/fs/cgroup/systemd

Prave cgroups umoznuje definovat cely strom procesu a systemd (a i admin systemu) ma pak pekny prehled o tom jake procesy jsou kde (v jake skupine).

viz. treba

    $ systemctl status dbus.service
    $ systemd-cgls

[D.A.Tiger]

Vypadá to zajímavě.

Nebylo by špatné, když už INIT systém řeší start služeb/demonu při startu systému, vložit do toho ještě funkčnost centrálního nastavení a startu aplikací při loginu. Osobně to řeším tak, že mám jednoduchou aplikaci, která se o to stará a přidávám do nastavení autostartu prostředí, která používám, pouze odkaz na tuto aplikaci. jenže to je taková z nouze cnost...

Je hezké že jsou procesy sledovány a v případě, že ztratí své rodičovské procesy, jsou automaticky ukončovány procesem init. Ale občas by se hodila přesně opačná vlastnost - při startu dané aplikace ji vyvázat (bez nutnosti využívání nějakých triků, třeba i s tím, že by bylo nutné zadat nový rodičovský proces... ). Některá prostředí to řeší alespoň tak, že na pozadí spustí samostatný proces, kterému jsou potom předávány požadavky na spuštění konkrétní aplikace a které jsou jejich rodičovskými procesy. Jenže ani to není úplně ideální...

[Boris Dušek]

Vypadá to zajímavě.

Nebylo by špatné, když už INIT systém řeší start služeb/demonu při startu systému, vložit do toho ještě funkčnost centrálního nastavení a startu aplikací při loginu.

launchd to řeší, systemd se inspiroval u launchd => asi to systemd bude řešit taky (myslím, že jsem to i explicitně četl, ale nechci to teď hledat)

[Michal Vyskočil]

Systemd podporuje režimy --system a --user, přičemž ten druhý je míněn jako náhrada za dnešní správce uživatelských relací. V praxi tak bude na jednom počítači systemd s pid 0 i další uživatelské instance.

[maleprase]

V praxi tak bude na jednom počítači systemd s pid 0

init ma pid 1

[Michal Vyskočil]

Jasně - pitomý překlep

[kralyk z abclinuxu]

Dík za zajímavý článek.

[kralyk z abclinuxu]

Jedna věc mi není jasná. U toho spouštění služeb na požádání, jestli to dobře chápu, tak systemd vytvoří socket dopředu a službu spustí, až když se někdo chce na ten socket připojit. Odkud ale systemd ví, jak ten socket vytvořit - s jakými parametry (port, adresa, ...)?
Třeba u takovýho http serveru je tohle záležitost konfigurace http deamona, ne?

[maleprase]

systemd se to dozvi z .socket souboru, napr. pro dovecot:

[Socket]
#dovecot expects separate IPv4 and IPv6 sockets
BindIPv6Only=ipv6-only
ListenStream=0.0.0.0:143
ListenStream=[::]:143
ListenStream=0.0.0.0:993
ListenStream=[::]:993

daemon potom vubec port neotvira, pripravi ho systemd, nastavi procesu promenne prostredi LISTEN_PID a LISTEN_FDS a "posle" ho demonovi s exec-em.

demony pak nekonfigurujes pres jejich vlastni konfigurak ale pres konfiguracni soubory initu. vyhoda?

[Michal Vyskočil]

Parametry jsou popsány v .socket jednotkách. Navíc, pokud konfigurujeme nastavení takto externě, nemusí se o to běžící proces nijak zajímat, protože ten pouze dostane už nastavený popisovač.