Systemd – jednotky a závislosti

1. 6. 2011 | Michal Vyskočil | Systém | 14507×

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. V dnešním díle se zaměříme přímo na jednotky, syntaxi souborů, ukážeme si systém explicitních závislostí a ostatní volby a nakonec i způsob, jak zkoumat závislosti jednotek systemd.

Obsah

• Jednotka systemd
• Stručný přehled syntaxe
• Obecné volby
• Explicitní závislosti
• Ostatní volby
  • Instalační volby
• Závěrem

Jednotka systemd

Jedním z Lennartových požadavků na dobrý init systém je deklarativní popis. To má dva hlavní důvody – shell skripty se poměrně dlouho zpracovávají a vykonávají. Především je init skript plný výplňového kódu, který vesměs duplikuje činnosti, které může stejně tak dobře provádět samotný init systém. Navíc jsou deklarativní popisy přehlednější a kratší. K tomu je systemd s /etc/init.d skripty zpětně kompatibilní, včetně podpory LSB hlaviček.

Stručný přehled syntaxe

Zpět k jednotkám (units). Syntaxe souborů je prostá – vychází z .desktop souborů freedesktop.org, které jsou zase odvozeny z INI souborů systému Windows (a doufejme, že nikdo nevytvoří syntax inspirovanou jednotkami systemd, vycházející z .desktop souborů, ...).

Konfigurace je tedy rozdělena do sekcí, jako [Unit], [Service], nebo [Install]. Samotné volby jsou potom psány ve formátu Název=Argument. Na každém řádku jedna. Na neznámé hodnoty reaguje démon výpisem varování do logu, názvy začínající na x- jsou úplně ignorovány. Pravdivostní argumenty mohou být yes, true, on nebo 1 a jejich protějšky zase no, false, off či 0.

Prázdné řádky a ty začínající na # jsou ignorovány a dlouhé řádky mohou být rozděleny pomocí zpětného lomítka. Pokud se očekává časová hodnota, výchozí hodnotou jsou sekundy, jinak jsou podporovány s, min, h, d, w, ms a us. Podporováno je také skládání – 6m 20s je chápáno jako 6 minut a 20 sekund.

Největším rozdílem od .desktop souborů je direktiva .include následovaná názvem souboru. Soubor uvedený jako argument je přečten a jeho obsah zpracován v kontextu příslušné jednotky.

Obecné volby

Následující volby jsou stejné pro všechny jednotky a jsou uvedeny v sekci [Unit].

Names= je alternativní název jednotky. Může být jeden či více a systemd bude rozpoznávat stejnou jednotku pod více názvy. Podmínkou je pochopitelně stejný typ jednotky. Příkladem je graphical.target, jehož Names= obsahuje runlevel5.target.

Description= je popis funkce jednotky. Očekává se, že popisky budou později lokalizovány podobně, jako soubory .desktop. Tato volba se v systemd nijak nezpracovává a očekává se, že s ním budou pracovat uživatelské programy.

Explicitní závislosti

Requires= je závislost na další jednotce. I když to může znít překvapivě, tak systemd nevyužívá jenom implicitní závislosti a odložené spuštění, ale rovněž podporuje explicitně uvedené závislosti. Všechny jednotky uvedené jako argument této volby jsou aktivovány společně s touto jednotkou a pokud bude některá z nich deaktivována, nebo spadne, tato jednotka bude deaktivována také.

Tato volba nijak nespecifikuje pořadí, v němž se budou služby spouštět, takže ve výchozím stavu budou spuštěny obě paralelně. Parametry After= a Before= určují pořadí spouštění.

Tato silná závislost bývá nejčastěji u .target jednotek. Třeba runlevel5.target obsahuje Requires=multi-user.target.

Příklad

Mějme jednotku a.service, která vypadá takto (vypíše do systémového logu informaci o tom, že byla spuštěna/ukončena).

Jednotky instalujeme kopírováním do /etc/systemd/system a zavoláním systemctl daemon-reload.

[Unit]
Description=unit %n

[Service]
Type=oneshot
ExecStart=-/bin/echo "unit %n started"
ExecStop=-/bin/echo "unit %n stopped"
StandardOutput=syslog

A další jednotku b.service s Requires a After a.service. Potom si příkazem systemctl snadno ověříme, že závislosti pracují, jak mají.

# systemctl start b.service
# systemctl status a.service
a.service – unit a.service
      Loaded: loaded (/etc/systemd/system/a.service)
      Active: active (exited) since Tue, 24 May 2011 16:57:18 +0200; 2s ago
     Process: 1184 ExecStart=/bin/echo unit %n started (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/a.service

A v logu nalezneme zmínky o správném pořadí – nejprve je spuštěna služba a, potom teprve b.

RequiresOverridable= je slabší varianta Requires=. Liší se tím, že jednotky zde uvedené jsou ignorovány, pokud nelze jejich závislost splnit, anebo spadnou při zavádění. Ovšem pouze v případě ruční aktivace. Jestliže je tato jednotka aktivována pro splnění závislosti na jiné jednotce a tyto závislé jednotky nelze zavést, problémy ignorovány nejsou a transakce se ukončí.

Requisite=, RequisiteOverridable= jsou podobné volbám Requires a RequiresOverridable s tím rozdílem, že pokud zadané jednotky již nejsou aktivní, transakce se okamžitě ukončí.

Příklad

Vytvořme si jednotku c.service s Requisite=a.service. Potom se náš příklad systemctl změní na

# systemctl stop a.service
# systemctl start c.service
A dependency job failed. See system logs for details.

A v systémovém logu uvidíme něco podobného (pro příklad je použit systemd.log_level=debug)

systemd[1]: Job a.service/verify-active finished, result=skipped
systemd[1]: Job c.service/start finished, result=dependency
systemd[1]: Job c.service/start failed with result 'dependency'.

Wants= je slabší variantou Requires=, protože chyba při spouštění závislé jednotky nemá vliv na celou transakci. Je to doporučený postup, jak specifikovat závislosti. A jak již asi všichni pochopili, adresář foo.target.wants/ je alternativním zdrojem závislostí typu Wants=.

Příklad

Vytvořme si jednotky f.service, která bude mít ExecStart=/bin/false, tedy vždy selže, a jednotku d.service, která bude mít Wants=f.service.

# systemctl start d.service
# systemctl status d.service
d.service – unit d.service
      Loaded: loaded (/etc/systemd/system/d.service)
      Active: active (exited) since Wed, 25 May 2011 09:53:47 +0200; 6s ago
     Process: 1118 ExecStart=/bin/echo unit %n started (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/d.service

Při změně závislosti na Requires uvidíme toto:

# systemctl start d.service
A dependency job failed. See system logs for details.

Conflicts= je negativní závislost a znamená, že obě jednotky nemohou být nastartovány vedle sebe. Start jedné ukončí druhou a podobně. Stejně jako Requires= je i zde možno pořadí specifikovat parametry After= a Before=. Systemd pamatuje i na případy, že by pro dokončení transakce bylo potřeba aktivovat navzájem konfliktní jednotky. Taková situace vede k ukončení transakce, ovšem až potom, co se systemd pokusí konflikt vyřešit vynecháním volitelných závislostí. Typicky většina jednotek je v konfliktu se shutdown.target.

Příklad

Zkusme jednotku e.service, která bude v konfliktu s libovolnou jednotkou, třeba a.service.

# systemctl start a.service
# systemctl status a.service
a.service – unit a.service
      Loaded: loaded (/etc/systemd/system/a.service)
      Active: active (exited) since Wed, 25 May 2011 09:58:10 +0200; 4s ago
     Process: 1513 ExecStart=/bin/echo unit %n started (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/a.service
# systemctl start e.service
# systemctl status a.service
a.service – unit a.service
      Loaded: loaded (/etc/systemd/system/a.service)
      Active: inactive (dead) since Wed, 25 May 2011 09:58:24 +0200; 1s ago
     Process: 1522 ExecStop=/bin/echo unit %n stopped (code=exited, status=0/SUCCESS)
     Process: 1513 ExecStart=/bin/echo unit %n started (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/a.service

Uvidíme, že při spuštění této jednotky dojde k zastavení jednotky a.service.

Before=, After= jsou volby určující pořadí spouštění mezi jednotkami. Pokud existuje požadavek na spuštění dvou jednotek, z nichž jedna má parametr Before=, start druhé je pozdržen do té doby, než se spustí první. After= je stejná volba, pouze s opačným významem. První by se nastartovala druhá jednotka a teprve poté první. V případě ukončení jednotky systemd pořadí otáčí, takže první se nejprve vypne jednotka, která nastartovala později. Bývá rozumné pro závislosti typu After= specifikovat rovněž stejnou závislost typu Requires=.

Příkladem závislosti After= je reboot.target, který obsahuje Requires=reboot.service a After=reboot.service, což znamená, že se tento cíl provede až po spuštění reboot.service. Opačnou závislost má například udev-retry.service Before=basic.target.

Příklad

Závislost typu After jsme měli už v prvním příkladě závislosti typu Requires. V tomto případě si ukážeme, jak funguje ortogonalita Requires a After a Before.

Mějme jednotky x.service a y.service

# x.service
[Unit]
Description=unit %n
Requires=y.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/bin/echo "unit %n started"
ExecStop=-/bin/echo "unit %n stopped"
StandardOutput=syslog

# y.service
[Unit]
Description=unit %n
Before=x.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/bin/echo "unit %n started"
ExecStop=-/bin/echo "unit %n stopped"
StandardOutput=syslog

Takto napsané jednotky způsobí při systemctl start x.service spuštění jednotky y a po ní teprve x, což může být pro někoho matoucí. Volba Requires totiž může pro někoho intuitivně obsahovat i pořadí. Proto je nejlepší psát:

Requires=foo.bar
After=foo.bar

a odstranit volby Before= z jednotky y, což zaručí očekávané chování. I když systemd ve verzi 27 volby z jednotky y ignoruje a stejně spustí jednotku x a potom teprve y, je lepší nemít matoucí volby v různých jednotkách.

A co se stane v případě, že volby Before= odstraníme? V tom případě se obě dvě jednotky spustí paralelně.

Ostatní volby

OnFailure= specifikuje jednotky spuštěné v případě, že tato jednotka vejde do chybového stavu.

RecursiveStop= očekává boolean argument, který určuje, zda se v případě automatické aktivace mají ukončit i závislé jednotky, nebo ne. Ve výchozím stavu je tato volba zakázána, což znamená, že závislé jednotky jsou automaticky ukončeny pouze v případě, že o to uživatel požádá.

StopWhenUnneeded= očekává boolean argument, který říká, že jednotka má být ukončena, pokud není dlouho využívána a neexistuje další aktivní jednotka, která by ji vyžadovala. Výchozím stavem je false, tudíž aktivovaná jednotka bude ukončena, pouze pokud je v konfliktu s další nebo na uživatelskou žádost. Z výchozích jednotek je tato volba aktivována třeba v bluetooth.target nebo printer.target.

RefuseManualStart=, RefuseManualStop= jsou volby pro jednotky, které nemohou být aktivovány nebo pozastaveny přímo uživatelem. Jejich běh či konec je možné vyvolat pouze nepřímo přes závislost na jiné jednotce. Příklady jsou basic.target nebo umount.target. Výchozí hodnota je false.

AllowIsolate= určuje, zda se jednotka může použít jako parametr příkazu systemctl isolate, nebo nikoli. Tento příkaz je nebezpečný; jelikož ukončuje všechny ostatní jednotky a ponechává spuštěnou pouze zadanou jednotku a její závislosti, je výchozí hodnota false. Jednotky emergency.target nebo multi-user.target mají tuto volbu povolenu.

DefaultDependencies= určuje, zda má systemd jednotce přidat implicitní (výchozí) závislosti. Ve výchozím stavu je tato volba povolena. Konkrétní podoba závislostí závisí na typu jednotky, takže jednotky typu .service dostanou závislost na spuštění systému a budou v konfliktu s jeho ukončením. Tato volba je určena především pro jednotky určené pro běh brzy po startu nebo těsně před ukončením jako umount.target nebo udev.service.

IgnoreDependencyFailure= je volba, která určuje reakci na selhání závislé jednotky. Ve výchozím stavu je tato volba zakázána, takže jednotka selže rovněž. Pokud je povolena, selhání závislé jednotky nemá na start vliv.

JobTimeoutSec= určuje, po jak dlouhou dobu mají závislé jednotky čekat na aktivaci jednotky. Po vypršení této doby je úloha zrušena a stav jednotky se nijak nezmění. Výchozí hodnota je 0 a bývá povolena v jednotkách typu .device.

Instalační volby

Mimo sekce [Unit] existuje ještě obecná sekce [Install]. Ta je určena výhradně pro příkazy systemctl enable a systemctl disable, které aktivují, nebo zakazují jednotky.

Alias= jsou další jména, pod nimiž by měla být jednotka nainstalována. Argumentem může být jedna, nebo několik jmen. Při instalaci dané jednotky příkaz systemctl enable vytvoří symbolické odkazy a příkaz systemctl disable je zase smaže.

Tato volba je odlišná od volby Names=, která má vliv pouze, pokud je jednotka aktivní. Obvykle je rozumné uvádět v obou variantách stejné názvy, takže jednotka bude dostupná pod nainstalovanými i pod alternativními názvy.

Příkladem použití této volby je getty@.service

[Install]
Alias=getty.target.wants/getty@tty1.service
getty.target.wants/getty@tty2.service getty.target.wants/getty@tty3.service
getty.target.wants/getty@tty4.service getty.target.wants/getty@tty5.service
getty.target.wants/getty@tty6.service

Příkaz systemctl enable vytvoří potřebné symbolické odkazy v adresáři getty.target.wants. Používat systemctl disable getty@.service, který odkazy smaže, je možné, ovšem není dvakrát rozumné.

WantedBy= instaluje symbolický odkaz do adresáře .wants/, takže jde o zpětnou závislost Wants=. Tato volba má ten efekt, že pokud je aktivována jednotka uvedená jako argument, tato jednotka bude aktivována rovněž.

Příkladem je cron.service a jeho WantedBy=multi-user.target nebo cryptsetup.target s volbou WantedBy=local-fs.targe.

Also= určuje další jednotky, které se mají instalovat, pokud je instalována tato jednotka. Jednotka avahi-daemon.service obsahuje volbu Also=avahi-daemon.socket

Závěrem

Můžete si stáhnout všechny ukázkové soubory v jednom balíčku.

V tomto výčtovém díle jsme se podívali na obecné parametry jednotek systemd. Zjistili jsme, že systemd disponuje pokročilým systémem explicitních závislostí a spoustou voleb, které chování jednotek dále upravují. Seznámili jsme se rovněž se sekcí [Install], která je důležitá při instalaci jednotek. Rovněž umíme zkoumat závislosti jednotek.

Následující díl se bude věnovat problematice unixových démonů.

       

Komentáře

[michich]

Names= se nedoporučuje používat. Symlink je jednodušší a méně zrádný. I ten runlevel5.target je už řešen symlinkem.

[michich]

RecursiveStop= už od verze 12 neexistuje. Místo toho jsou volby BindTo= a BoundBy=.

[Michal Vyskočil]

To je pravda - nicméně pokud vím, tak nejstarší manuálové stránky, které jsem používal jako zdroj byly ze systemd-16, kde RecursiveStop byl. Ale díky za upozornění, musím změny mezi vydáními kontrolovat o něco pečlivěji.

[michich]

Popis u StopWhenUnneeded= je matoucí. Žádná doba nevyužívání se nesleduje. Unit je ukončen ihned, jakmile už není žádný aktivní jiný unit, který by měl Requires=, Wants=, apod. na tento unit.