Portál AbcLinuxu, 19. říjen 2017 10:06

Systemd – vlastnosti a schopnosti

23. 3. 2011 | Michal Vyskočil
Články - Systemd – vlastnosti a schopnosti  

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

link

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ů

link

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í

link

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

link

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ů

link

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ů

link

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ů

link

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í updatebIOPRIO_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

link

Status update

link

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.

Závěrem

link

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.

Seriál Systemd (dílů: 7)

První díl: Systemd – úvod a představení System V init, poslední díl: Systemd – .service jednotky, náhrada init skriptů.
Předchozí díl: Systemd – úvod a představení System V init
Následující díl: Systemd – principy

Další články z této rubriky

Paralelizace běžných činností v konzoli pomocí GNU Parallel
Unixové nástroje – 26 (triky pro práci v Bashi)
Unixové nástroje – 25 ((s,c)fdisk, gdisk, parted a findmnt)
Linux: systémové volání splice()
Bootování ze sítě: pxelinux a kořenový adresář na NFS

Diskuse k tomuto článku

23.3.2011 10:08 Xerces
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Odpovědět | Sbalit | Link | Blokovat | Admin
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.
23.3.2011 18:06 Jan Molič
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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ě).
23.3.2011 19:55 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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.

12.5.2011 07:22 Xerces
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Díky za názor. Na OpenRC se podívám, nějak mne minul.
23.3.2011 10:55 ext3fs
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Odpovědět | Sbalit | Link | Blokovat | Admin
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 avatar 23.3.2011 12:58 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
1/ Pad poznaji tak ze proces skonci. Ukonceni poznaji tak ze jsou pozadani aby proces ukoncili. sysv init to dela stejne.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
23.3.2011 14:53 ext3fs
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Ale co kdyz proces neni ukoncen radnou cestou ale spadne? Treba na nedostatek pameti. Jak vi, ze jej maji znovu startovat?
23.3.2011 13:39 Karel Zak | blog: kzak
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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 avatar 23.3.2011 15:23 D.A.Tiger | skóre: 8 | Brno
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Odpovědět | Sbalit | Link | Blokovat | Admin
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í...

Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
23.3.2011 16:32 Boris Dušek | skóre: 22 | blog: everything
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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)
vim ~/.emacs
24.3.2011 11:42 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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.
When your hammer is C++, everything begins to look like a thumb.
24.3.2011 12:15 maleprase | skóre: 28
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
V praxi tak bude na jednom počítači systemd s pid 0

init ma pid 1
24.3.2011 13:21 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Jasně - pitomý překlep :-D
When your hammer is C++, everything begins to look like a thumb.
oryctolagus avatar 23.3.2011 21:55 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Odpovědět | Sbalit | Link | Blokovat | Admin
Dík za zajímavý článek.
Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
oryctolagus avatar 24.3.2011 10:25 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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?
Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
24.3.2011 12:36 maleprase | skóre: 28
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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?
24.3.2011 13:20 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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č.
When your hammer is C++, everything begins to look like a thumb.

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.