abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 1
dnes 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 2
dnes 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 1
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 993 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Systemd – jednotky a závislosti

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

    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

    link

    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

    link

    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

    link

    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

    link

    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

    link

    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.serviceRequires 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

    link

    Vytvořme si jednotku c.serviceRequisite=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

    link

    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

    link

    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

    link

    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

    link

    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

    link

    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

    link

    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ů.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    michich avatar 1.6.2011 16:31 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Systemd – jednotky a závislosti
    Names= se nedoporučuje používat. Symlink je jednodušší a méně zrádný. I ten runlevel5.target je už řešen symlinkem.
    michich avatar 1.6.2011 16:55 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Systemd – jednotky a závislosti
    RecursiveStop= už od verze 12 neexistuje. Místo toho jsou volby BindTo= a BoundBy=.
    2.6.2011 08:58 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Systemd – jednotky a závislosti
    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.
    When your hammer is C++, everything begins to look like a thumb.
    michich avatar 1.6.2011 16:57 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Systemd – jednotky a závislosti
    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.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.