Naučit se milovat systemd

systemd – ano, všechna malá písmena, dokonce i na začátku věty – je moderní náhradou init a SystemV init skriptů. Je to také mnohem více.

Jako většina sysadminů, když myslím na program init a SystemV, myslím na spouštění a vypínání Linuxu a nic jiného, ​​jako je správa služeb, jakmile jsou v provozu. Stejně jako init je systemd matkou všech procesů a je zodpovědný za uvedení hostitele Linuxu do stavu, ve kterém lze provádět produktivní práci. Některé z funkcí převzatých systemd, který je mnohem rozsáhlejší než starý program init, je správa mnoha aspektů běžícího hostitele Linuxu, včetně připojování souborových systémů, správy hardwaru, manipulace s časovači a spouštění a správy systémových služeb, které jsou vyžadovány. mít produktivního hostitele Linuxu.

Tato série článků, která je částečně založena na výňatcích z mého třídílného školení o Linuxu Používání a správa Linuxu:nula do sysadmin , zkoumá funkce systemd jak při spuštění, tak na začátku po dokončení spuštění.

Spuštění Linuxu

Celý proces, který převede hostitele Linuxu z vypnutého stavu do stavu běhu, je složitý, ale je otevřený a poznatelný. Než se pustím do podrobností, poskytnu stručný přehled od zapnutí hostitelského hardwaru do doby, kdy je systém připraven na přihlášení uživatele. O „procesu spouštění“ se většinou mluví jako o jedné entitě, ale to není přesné. Celý proces spouštění a spouštění má ve skutečnosti tři hlavní části:

• Hardwarové spouštění: Inicializuje systémový hardware
• Zavedení Linuxu: Načte linuxové jádro a poté systemd
• Spuštění Linuxu: Kde systemd připravuje hostitele na produktivní práci

Spouštěcí sekvence Linuxu začíná po načtení jádra buď init nebo systemd, v závislosti na tom, zda distribuce používá staré nebo nové spuštění. Programy init a systemd spouštějí a spravují všechny ostatní procesy a oba jsou známé jako „matka všech procesů“ ve svých příslušných systémech.

Je důležité oddělit spouštění hardwaru od spouštění Linuxu od spouštění Linuxu a explicitně definovat demarkační body mezi nimi. Pochopení těchto rozdílů a toho, jakou roli každý hraje při uvedení linuxového systému do stavu, kdy může být produktivní, umožňuje řídit tyto procesy a lépe určit, kde dochází k problému během toho, co většina lidí nazývá „boot“.

Proces spouštění následuje po třífázovém procesu spouštění a uvádí počítač se systémem Linux do provozního stavu, ve kterém je použitelný pro produktivní práci. Proces spouštění začíná, když jádro předá kontrolu nad hostitelem systemd.

systémová kontroverze

systemd může vyvolat širokou škálu reakcí od systémových administrátorů a dalších odpovědných za udržování linuxových systémů v chodu. Skutečnost, že systemd přebírá tolik úkolů v mnoha linuxových systémech, vyvolala odpor a neshody mezi určitými skupinami vývojářů a systémových administrátorů.

SystemV a systemd jsou dvě různé metody provádění spouštěcí sekvence Linuxu. Spouštěcí skripty SystemV a program init jsou staré metody a systemd using targets je nová metoda. Ačkoli většina moderních linuxových distribucí používá pro spouštění, vypínání a správu procesů novější systemd, stále existují některé, které tak neučiní. Jedním z důvodů je, že někteří správci distribuce a někteří správci systému preferují starší metodu SystemV před novějším systemd.

Myslím, že obojí má výhody.

Proč preferuji SystemV

Preferuji SystemV, protože je otevřenější. Spuštění se provádí pomocí skriptů Bash. Poté, co jádro spustí program init, což je zkompilovaný binární soubor, init spustí rc.sysinit skript, který provádí mnoho úloh inicializace systému. Po rc.sysinit dokončí, init spustí /etc/rc.d/rc skript, který zase spouští různé služby definované spouštěcími skripty SystemV v /etc/rc.d/rcX.d , kde "X" je číslo spouštěné úrovně běhu.

Další zdroje pro Linux

• Cheat pro příkazy Linuxu
• Cheat sheet pro pokročilé příkazy systému Linux
• Bezplatný online kurz:Technický přehled RHEL
• Síťový cheat pro Linux
• Cheat sheet SELinux
• Cheat pro běžné příkazy pro Linux
• Co jsou kontejnery systému Linux?
• Naše nejnovější články o Linuxu

Kromě samotného programu init jsou všechny tyto programy otevřené a snadno poznatelné skripty. Je možné číst tyto skripty a dozvědět se přesně, co se děje během celého procesu spouštění, ale nemyslím si, že to ve skutečnosti dělá mnoho systémových administrátorů. Každý spouštěcí skript je očíslován tak, aby spustil zamýšlenou službu v určitém pořadí. Služby se spouštějí sériově a vždy se spouští pouze jedna služba.

systemd, vyvinutý Lennartem Poetteringem z Red Hat a Kay Sievers, je komplexním systémem velkých kompilovaných binárních spustitelných souborů, které nejsou srozumitelné bez přístupu ke zdrojovému kódu. Jedná se o open source, takže „přístup ke zdrojovému kódu“ není obtížný, jen méně pohodlný. Zdá se, že systemd představuje významné vyvrácení mnoha principů filozofie Linuxu. Jako binární systém není systemd přímo otevřen pro správce systému, aby si mohl prohlížet nebo provádět snadné změny. systemd se snaží dělat vše, jako je správa běžících služeb, a přitom poskytovat podstatně více informací o stavu než SystemV. Také spravuje hardware, procesy a skupiny procesů, připojení souborového systému a mnoho dalšího. systemd je přítomen téměř ve všech aspektech moderního hostitele Linuxu, což z něj činí komplexní nástroj pro správu systému. To vše je jasným porušením zásad, že programy by měly být malé a že každý program by měl dělat jednu věc a dělat ji dobře.

Proč preferuji systemd

Dávám přednost systemd jako spouštěcímu mechanismu, protože spouští co nejvíce služeb paralelně v závislosti na aktuální fázi procesu spouštění. Tím se urychlí celkové spouštění a hostitelský systém se dostane na přihlašovací obrazovku rychleji než SystemV.

systemd spravuje téměř každý aspekt běžícího systému Linux. Dokáže spravovat běžící služby a zároveň poskytovat podstatně více informací o stavu než SystemV. Spravuje také hardware, procesy a skupiny procesů, připojení souborového systému a mnoho dalšího. systemd je přítomen téměř ve všech aspektech moderního operačního systému Linux, což z něj činí komplexní nástroj pro správu systému. (Zní vám to povědomě?)

Nástroje systemd jsou zkompilované binární soubory, ale sada nástrojů je otevřená, protože všechny konfigurační soubory jsou textové soubory ASCII. Spouštěcí konfiguraci lze upravit pomocí různých nástrojů GUI a příkazového řádku, stejně jako přidáním nebo úpravou různých konfiguračních souborů tak, aby vyhovovaly potřebám konkrétního místního výpočetního prostředí.

Skutečný problém

Mysleli jste si, že se mi oba startovací systémy nelíbí? Já ano a mohu pracovat s oběma.

Podle mého názoru je skutečným problémem a hlavní příčinou většiny kontroverzí mezi SystemV a systemd to, že na úrovni systémového správce neexistuje žádná volba. Rozhodnutí, zda použít SystemV nebo systemd, již učinili vývojáři, správci a baliči různých distribucí – ale z dobrého důvodu. Vyjmutí a nahrazení init systému má díky jeho extrémní, invazivní povaze mnoho důsledků, které by bylo těžké řešit mimo proces návrhu distribuce.

Navzdory skutečnosti, že tato volba je pro mě, moji hostitelé Linuxu se spustí a fungují, což je to, na čem mi obvykle záleží nejvíce. Jako koncový uživatel a dokonce i jako správce systému je mým hlavním zájmem, zda zvládnu svou práci, práci, jako je psaní knih a tohoto článku, instalace aktualizací a psaní skriptů pro automatizaci všeho. Dokud můžu dělat svou práci, nezajímá mě vlastně startovací sekvence používaná v mé distribuci.

Zajímá mě, když se vyskytne problém při spouštění nebo správě služeb. Bez ohledu na to, který spouštěcí systém se na hostiteli používá, vím dost na to, abych sledoval sled událostí, abych našel chybu a napravil ji.

Výměna SystemV

Již dříve existovaly pokusy nahradit SystemV něčím trochu modernějším. Asi ve dvou verzích Fedora používala věc nazvanou Upstart k nahrazení stárnoucího SystemV, ale nenahradila init a neposkytla žádné změny, kterých jsem si všiml. Protože Upstart nepřinesl žádné významné změny v otázkách týkajících se SystemV, úsilí v tomto směru bylo rychle upuštěno ve prospěch systemd.

Navzdory skutečnosti, že většina linuxových vývojářů souhlasí s tím, že nahrazení starého startu SystemV je dobrý nápad, mnoho vývojářů a systémových administrátorů to systemd nesnáší. Spíše než opakovat všechny takzvané problémy, které lidé mají – nebo měli – se systemd, vás odkážu na dva dobré, i když poněkud staré články, které by měly pokrývat většinu všeho. Linus Torvalds, tvůrce linuxového jádra, se zdá být nezaujatý. V článku ZDNet z roku 2014 Linus Torvalds a další na systému Linux , Linus má o svých pocitech jasno.

"Ve skutečnosti nemám žádné zvlášť vyhraněné názory na samotný systemd. Měl jsem problémy s některými základními vývojáři, o kterých si myslím, že jsou příliš lstiví ohledně chyb a kompatibility, a myslím si, že některé detaily návrhu jsou šílené (I nelíbí se mi například binární protokoly), ale to jsou detaily, nikoli velké problémy."

V případě, že toho o Linusovi moc nevíte, mohu vám říci, že pokud se mu něco nelíbí, je velmi otevřený, explicitní a zcela jasný v této nechuti. Stal se společensky přijatelnějším způsobem, jak vyjadřovat svou nechuť k věcem.

V roce 2013 napsal Poettering dlouhý blogový příspěvek, ve kterém boří mýty o systemd a zároveň poskytuje pohled na některé důvody, proč jej vytvořil. Toto je velmi dobré čtení a vřele doporučuji.

systémové úlohy

V závislosti na možnostech použitých během procesu kompilace (které nejsou v této sérii brány v úvahu), systemd může mít až 69 binárních spustitelných souborů, které provádějí mimo jiné následující úkoly:

• Program systemd běží jako PID 1 a poskytuje spouštění systému co nejvíce služeb paralelně, což jako vedlejší efekt zrychluje celkové doby spouštění. Řídí také vypínací sekvenci.
• Program systemctl poskytuje uživatelské rozhraní pro správu služeb.
• Pro zpětnou kompatibilitu je nabízena podpora pro spouštěcí skripty SystemV a LSB.
• Správa služeb a hlášení poskytují více údajů o stavu služby než SystemV.
• Zahrnuje nástroje pro základní konfiguraci systému, jako je název hostitele, datum, národní prostředí, seznamy přihlášených uživatelů, spuštěné kontejnery a virtuální stroje, systémové účty, runtime adresáře a nastavení, démoni pro správu jednoduché konfigurace sítě, synchronizace času v síti , přeposílání protokolů a rozlišení jmen.
• Nabízí správu soketů.
• Časovače systemd poskytují pokročilé funkce podobné cronu, které zahrnují spouštění skriptu v časech souvisejících se spouštěním systému, spouštění systemd, posledního spuštění časovače a další.
• Poskytuje nástroj pro analýzu dat a časů používaných ve specifikacích časovače.
• Připojování a odpojování souborových systémů s hierarchickým povědomím umožňuje bezpečnější kaskádování připojených souborových systémů.
• Umožňuje pozitivní vytváření a správu dočasných souborů, včetně mazání.
• Rozhraní pro D-Bus poskytuje možnost spouštět skripty, když jsou zařízení připojena nebo odpojena. To umožňuje, aby se se všemi zařízeními, ať už připojitelnými nebo ne, zacházelo jako se zařízením plug-and-play, což značně zjednodušuje manipulaci se zařízeními.
• Jeho nástroj pro analýzu spouštěcí sekvence lze použít k vyhledání služeb, které zabírají nejvíce času.
• Zahrnuje žurnály pro ukládání zpráv systémových protokolů a nástroje pro správu žurnálů.

Architektura

Tyto a další úlohy jsou podporovány řadou démonů, řídicích programů a konfiguračních souborů. Obrázek 1 ukazuje mnoho komponent, které patří k systemd. Toto je zjednodušený diagram navržený tak, aby poskytoval přehled na vysoké úrovni, takže nezahrnuje všechny jednotlivé programy nebo soubory. Neposkytuje ani žádný pohled na tok dat, který je tak složitý, že by to v kontextu této série článků bylo zbytečné.

Úplná expozice systemd by sama o sobě zabrala knihu. Nemusíte chápat detaily toho, jak do sebe systémové komponenty na obrázku 1 zapadají; stačí vědět o programech a komponentách, které umožňují správu různých linuxových služeb a zabývají se log soubory a žurnály. Ale je jasné, že systemd není ta monolitická zrůdnost, za kterou se někteří její kritici domnívají.

systemd jako PID 1

systemd je PID 1. Některé z jeho funkcí, které jsou mnohem rozsáhlejší než starý program SystemV3 init, zahrnují správu mnoha aspektů běžícího hostitele Linuxu, včetně připojování souborových systémů a spouštění a správy systémových služeb, které jsou nutné pro produktivního hostitele Linuxu. Všechny úlohy systemd, které se netýkají spouštěcí sekvence, jsou mimo rozsah tohoto článku (ale některé budou prozkoumány později v této sérii).

Nejprve systemd připojí souborové systémy definované v /etc/fstab , včetně všech odkládacích souborů nebo oddílů. V tomto okamžiku má přístup ke konfiguračním souborům umístěným v /etc , včetně svého vlastního. Používá svůj konfigurační odkaz, /etc/systemd/system/default.target , abyste určili, do kterého stavu nebo cíle má zavést hostitele. default.target soubor je symbolický odkaz na skutečný cílový soubor. U stolních pracovních stanic to bude obvykle graphical.target , což je ekvivalentní úrovni běhu 5 v SystemV. U serveru je výchozí nastavení pravděpodobnější multi-user.target , což je jako runlevel 3 v SystemV. emergency.target je podobný režimu pro jednoho uživatele. Cíle a služby jsou systémové jednotky.

Níže uvedená tabulka (obrázek 2) porovnává cíle systemd se starými úrovněmi spuštění SystemV. systemd poskytuje cílové aliasy systemd pro zpětnou kompatibilitu. Cílové aliasy umožňují skriptům – a mnoha správcům systému – používat příkazy SystemV jako init 3 změnit úrovně běhu. Příkazy SystemV jsou samozřejmě předávány systemd k interpretaci a provedení.

systémové cíle	Úroveň běhu SystemV	cílové aliasy	Popis
default.target			Tento cíl má vždy alias se symbolickým odkazem buď na multi-user.target nebo graphical.target . systemd vždy používá default.target ke spuštění systému. default.target by nikdy neměl být přiřazen k halt.target , poweroff.target nebo reboot.target .
graphical.target	5	runlevel5.target	Multi-user.target s GUI
	4	runlevel4.target	Nepoužité. Úroveň běhu 4 byla identická s úrovní běhu 3 ve světě SystemV. Tento cíl lze vytvořit a přizpůsobit tak, aby spouštěl místní služby, aniž by bylo nutné měnit výchozí multi-user.target .
multi-user.target	3	runlevel3.target	Všechny služby běží, ale pouze rozhraní příkazového řádku (CLI)
	2	runlevel2.target	Více uživatelů, bez NFS, ale běží všechny ostatní služby mimo GUI
rescue.target	1	runlevel1.target	Základní systém, včetně připojení souborových systémů se spuštěnými pouze nejzákladnějšími službami a záchranného shellu na hlavní konzoli
emergency.target	S		Režim pro jednoho uživatele – nejsou spuštěny žádné služby; souborové systémy nejsou připojeny. Toto je nejzákladnější úroveň provozu s pouze nouzovým shellem spuštěným na hlavní konzoli, aby uživatel mohl komunikovat se systémem.
halt.target			Zastaví systém bez jeho vypnutí
reboot.target	6	runlevel6.target	Restartovat
poweroff.target	0	runlevel0.target	Zastaví systém a vypne napájení

Každý cíl má sadu závislostí popsanou ve svém konfiguračním souboru. systemd spouští požadované závislosti, což jsou služby potřebné ke spuštění hostitele Linuxu na konkrétní úrovni funkčnosti. Když jsou načteny a spuštěny všechny závislosti uvedené v cílových konfiguračních souborech, systém běží na této cílové úrovni. Na obrázku 2 jsou cíle s největším počtem funkcí v horní části tabulky, přičemž funkčnost klesá směrem ke spodní části tabulky.

systemd se také podívá do starších inicializačních adresářů SystemV, aby zjistil, zda tam existují nějaké spouštěcí soubory. Pokud ano, systemd je použije jako konfigurační soubory ke spuštění služeb popsaných v souborech. Zastaralá síťová služba je dobrým příkladem služby, která stále používá spouštěcí soubory SystemV ve Fedoře.

Obrázek 3 (níže) je zkopírován přímo z manuálové stránky spouštění. Zobrazuje mapu obecné posloupnosti událostí během spouštění systemd a základní požadavky na uspořádání pro zajištění úspěšného spuštění.

 CryptSetup-pre.target 
 | 
 (různá nízkoúrovňová v 
 API VFS Montáž:(Různé zařízení CryptSetup ...) 
 MQueue, Configfs, | | 
  debugfs, ...)                                    v    |
  | cryptsetup.target  |
  | (různé swap                                 |    |    remote-fs-pre.target
  |   zařízení...)                                      | | |
  | | | | | v
  | v                       local-fs-pre.target | | | (síťové systémy souborů)
  | swap.target                       | | v     v                 |
  | | v           | remote-cryptsetup.target  |
  | | (Různá nízká úroveň (různé držáky a | | | | 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 #) | | />  |    |   seed, sysctl, ...)          v           | | /
  | | | local-fs.target    | | /
  | | | | | | /
  \____|______|_______________   ______|___________/             | /
                              \ /                                 | /
                               v                                 | /
                        sysinit.target                           | /
                               | | /
        ______________________/|\______________________           | /
       /              | | | \          | /
       | | | | | | /
       v              v        | v               | | /
  (různé       (různé      |  (různé            |          |/
   časovače...)      cesty...)   |   zásuvky...)        | |
       | | | | | |
       v              v        | v               | |
 times.target  paths.target   | sockets.target      | |
       | | | | v          |
       v              \_______ | _____/         rescue.service   |
                              \|/                     | | 
 v v | 
 basic.target rescue.target | 
 | |
                       ________v____________________             |
                                           \            |
                      | | | | 
 v v v v | 
 zobrazení- (Různý systém (jiný systém | 
 Manager.service Services Services) | 
 | Vyžaduje se | v            v
                      | | multi-user.target
 emergency.service    | | |
         | \______________ | „ 

 
 

 sysinit.target a basic.target cíle lze považovat za kontrolní body v procesu spouštění. Přestože jedním z cílů návrhu systemd je spouštět systémové služby paralelně, určité služby a funkční cíle musí být spuštěny dříve, než se mohou spustit jiné služby a cíle. Tyto kontrolní body nelze projít, dokud nejsou splněny všechny služby a cíle požadované tímto kontrolním bodem.
 

 sysinit.target je dosaženo, když jsou dokončeny všechny jednotky, na kterých závisí. Všechny tyto jednotky, připojování souborových systémů, nastavení odkládacích souborů, spouštění udev, nastavení počátečního bodu generátoru náhodných čísel, spouštění nízkoúrovňových služeb a nastavení kryptografických služeb (pokud je zašifrován jeden nebo více souborových systémů), musí být dokončeny, ale v rámci sysinit.target , tyto úlohy lze provádět paralelně.
 

 sysinit.target spouští všechny nízkoúrovňové služby a jednotky potřebné k tomu, aby byl systém okrajově funkční a které jsou nutné k přechodu na basic.target .
 

 Po sysinit.target Pokud je splněno, systemd poté spustí všechny jednotky potřebné ke splnění dalšího cíle. Základní cíl poskytuje některé další funkce spuštěním jednotek, které jsou vyžadovány pro všechny další cíle. Patří mezi ně nastavení věcí, jako jsou cesty k různým spustitelným adresářům, komunikační sokety a časovače.
 

 Konečně cíle na úrovni uživatele, multi-user.target nebo graphical.target , lze inicializovat. multi-user.target musí být dosaženo předtím, než budou splněny grafické cílové závislosti. Podtržené cíle na obrázku 3 jsou obvyklé cíle při spuštění. Po dosažení jednoho z těchto cílů je spuštění dokončeno. Pokud multi-user.target je výchozí, pak byste měli na konzoli vidět přihlášení v textovém režimu. Pokud graphical.target je výchozí, pak byste měli vidět grafické přihlášení; konkrétní přihlašovací obrazovka GUI, kterou uvidíte, závisí na vašem výchozím správci zobrazení.
 

 Manuálová stránka spouštění také popisuje a poskytuje mapy spouštění na počáteční disk RAM a proces vypínání systému.
 

 systemd také poskytuje nástroj, který uvádí závislosti úplného spuštění nebo pro určitou jednotku. Jednotka je ovladatelná entita systémového zdroje, která se může pohybovat od konkrétní služby, jako je httpd nebo sshd, po časovače, připojení, zásuvky a další. Zkuste následující příkaz a procházejte výsledky.
 
systemctl list-dependencies graphical.target 
 

 Všimněte si, že se tím plně rozšíří seznam cílových jednotek nejvyšší úrovně potřebný k převedení systému do režimu grafického cíle. Použijte --all možnost rozšířit také všechny ostatní jednotky.
 
systemctl list-dependencies --all graphical.target 
 

 Řetězce jako „target“, „slice“ a „socket“ můžete vyhledávat pomocí vyhledávacích nástrojů méně příkaz.
 

 Takže teď zkuste následující.
 
systemctl list-dependencies multi-user.target 
 

 a
 
systemctl list-dependencies rescue.target 
 

 a
 
systemctl list-dependencies local-fs.target 
 

 a
 
systemctl list-dependencies dbus.service 
 

 Tento nástroj mi pomáhá vizualizovat specifika spouštěcích závislostí pro hostitele, na kterém pracuji. Pokračujte a věnujte nějaký čas prozkoumání spouštěcího stromu pro jednoho nebo více vašich hostitelů Linuxu. Buďte však opatrní, protože manuálová stránka systemctl obsahuje tuto poznámku:
 
 

 "Všimněte si, že tento příkaz uvádí pouze jednotky aktuálně načtené do paměti správcem služeb. Tento příkaz zejména není vhodný k získání úplného seznamu všech zpětných závislostí na konkrétní jednotce, protože nevypisuje závislosti deklarováno jednotkami, které aktuálně nejsou načteny." 
 
 
Poslední myšlenky
 

 Ještě předtím, než se do systemd dostaneme hodně hluboko, je zřejmé, že je výkonný a komplexní. Je také zřejmé, že systemd není jediný, obrovský, monolitický a nepoznatelný binární soubor. Spíše se skládá z řady menších komponent a dílčích příkazů, které jsou navrženy k provádění konkrétních úkolů.
 

 Další článek této série podrobněji prozkoumá spouštění systemd, stejně jako konfigurační soubory systemd, změnu výchozího cíle a jak vytvořit jednoduchou servisní jednotku.
 
Zdroje
 

 Na internetu je k dispozici velké množství informací o systemd, ale mnohé jsou stručné, tupé nebo dokonce zavádějící. Kromě zdrojů zmíněných v tomto článku nabízejí následující webové stránky podrobnější a spolehlivější informace o spouštění systemd.
 
 
Projekt Fedora má dobrého praktického průvodce systemd. Obsahuje téměř vše, co potřebujete vědět, abyste mohli nakonfigurovat, spravovat a udržovat počítač Fedora pomocí systemd.
 
Projekt Fedora má také dobrý cheat sheet, který křížově odkazuje na staré příkazy SystemV se srovnatelnými příkazy systemd.
 
Podrobné technické informace o systemd a důvodech pro jeho vytvoření naleznete v popisu systemd na Freedesktop.org.
 
Pokročilejší systémové informace a tipy nabízí stránka Linux.com „More systemd fun“.
 
 

 Existuje také řada hluboce technických článků pro správce systému Linux od Lennarta Poetteringa, návrháře a primárního vývojáře systemd. Tyto články byly napsány mezi dubnem 2010 a zářím 2011, ale nyní jsou stejně aktuální jako tehdy. Většina všeho dobrého, co bylo napsáno o systemd a jeho ekosystému, je založeno na těchto dokumentech.
 
 
Přehodnocení PID 1
 
systemd pro administrátory, část I
 
systemd pro administrátory, část II
 
systemd pro administrátory, část III
 
systemd pro administrátory, část IV
 
systemd pro administrátory, část V
 
systemd pro administrátory, část VI
 
systemd pro administrátory, část VII
 
systemd pro administrátory, část VIII
 
systemd pro administrátory, část IX
 
systemd pro administrátory, část X
 
systemd pro administrátory, část XI