Hluboké poznatky o systému „Ubuntu Linux“ – vidíme to?

Dřívější verze Ubuntu před 6.10 obsahovaly starý styl sysvinit, který se používal ke spouštění skriptů v „/etc/rcx.d b> ” při každém spuštění a vypnutí systému. Poté však systém upstart nahradil starý systém sysvinit, ale stále mu poskytuje zpětnou kompatibilitu.

Nejnovější verze Ubuntu mají tento upstartovací systém, ale od jeho evoluce z Ubuntu 6.10 prošlo několik revizí aktuální verze 1.13.2 ze 4. září 2014. Nejnovější upstart systém má 2 init procesy, jeden pro systémové procesy a druhý, který spravuje aktuální relaci přihlášeného uživatele a existuje pouze do doby, než se uživatel přihlásí, také nazývaný x-session init .

Celý systém byl stanoven jako hierarchický, sestávající ze vztahu předek-dítě od výkonu až po vypnutí systému.

Například: Malý hierarchický vztah mezi oběma procesy init je: system init(1) -> správce zobrazení (prostor jádra) -> display manager(user space) -> user init (nebo x-session init).

Konfigurační soubory pro procesy spravované systémem init se nacházejí v „/etc/init “ a pro procesy spravované inicializací relace jsou uloženy v „/usr/share/upstart“ (jako podle aktuálních počátečních verzí výše 1.12) a tyto konfigurační soubory jsou klíčem k mnoha odhaleným tajemstvím o procesech, jak je popsáno v tomto článku.

Dostat se více hlouběji do hierarchie

Ubuntu rozeznává dva typy procesů:

1. Zaměstnání s krátkou životností (neboli práce typu work and die).
2. Dlouhodobá pracovní místa (nebo pracovní místa setrvání a práce).

Hierarchie, která je vytvořena v systému, je způsobena závislostním vztahem mezi procesy, kterému můžeme porozumět zobrazením jejich konfiguračních souborů. Začněme nejprve jednoduchým hierarchickým vztahem mezi procesy, díky nimž se systém spouští, a pochopme význam každého z nich.

Hierarchie zavádění

Init je první proces, který se spustí při zapnutí systému a je klasifikován jako úloha work-and-stay, protože se nikdy neukončí a je zapnuto pouze ukončení init vypnutí, tj. init umírá pouze a to také jednou za relaci, a to při vypnutí. Při zapnutí init vygeneruje úplně první událost v systému, tj. událost spuštění. Každý konfigurační soubor v „/etc/init“ má dva řádky, které definují událost, která způsobí spuštění a zastavení procesu. Tyto řádky jsou zvýrazněny na obrázku níže:

Toto je konfigurační soubor procesu failsafe-x a tyto podmínky spuštění a zastavení popisují událost, při které se proces spustí. Při generování spouštěcí události procesem init se ty procesy, které mají spuštění jako podmínku spuštění, provádějí paralelně a to pouze definuje hierarchii a všechny procesy, které se spouštějí při spuštění, jsou potomky init.

Procesy, které se spouštějí při spuštění, jsou uvedeny níže a toto jsou všechny úlohy typu work and die:

1. název hostitele – Toto je proces, který pouze sděluje systému své jméno hostitele definované v souboru /etc/hostname.

2. kmod – Načte moduly jádra, tj. všechny ovladače ze souboru /etc/modules.

3. mountall – Tento proces generuje mnoho událostí a je zodpovědný hlavně za připojení všech souborových systémů při zavádění, včetně lokálních a vzdálených souborových systémů.

Soubor /proc je také připojen právě tímto procesem a po všech připojovacích pracích je poslední událostí, kterou vygeneruje, událost souborového systému, která dále posouvá hierarchii dále.

4. plymouth – Tento proces se spustí při spuštění mountall a je zodpovědný za zobrazení černé obrazovky, která se zobrazuje při spuštění systému a zobrazuje něco jako níže:

5. Plymouth-ready – Označuje, že plymouth je nahoře.

Následují hlavní procesy, mezi další, které se také spouštějí při spuštění, patří například udev-fallback-graphics atd. Když se vrátíme k zaváděcí hierarchii, v kostce události a procesy, které následují, jsou následující:

1. iniciovat spolu s generováním spouštěcí události.

2. mountall připojuje souborové systémy, plymouth (spolu se spouštěním mountall) zobrazující úvodní obrazovku a kmod nahrává moduly jádra.

3. Událost local-filesystem generovaná mountall způsobující spuštění dbus. (Dbus je systémová sběrnice zpráv, která vytváří soket, který umožňuje ostatním procesům komunikovat mezi sebou prostřednictvím zasílání zpráv do tohoto soketu a přijímač naslouchá zprávám na tomto soketu a filtruje ty, které jsou pro něj určeny).

4. local-filesystem spolu se spuštěnou dbus a static-network-up událostí způsobenou procesní sítí, která také běží na lokální-filesystem událost způsobí spuštění správce sítě.

5. Událost virtual-filesystem generovaná mountall způsobí spuštění udev. (udev je správce zařízení pro linux, který spravuje připojování zařízení za provozu a je zodpovědný za vytváření souborů v adresáři /dev a také za jejich správu.) udev vytváří soubory pro ram, rom atd. v adresáři /dev ty, které mountall dokončil připojení virtuálního -filesystems a vygeneroval událost virtual-filesystem znamenající připojení adresáře /dev.

6. udev způsobí spuštění upstart-udev-bridge, což znamená, že místní síť je funkční. Poté, co mountall dokončil připojení posledního souborového systému a vygeneroval událost souborového systému.

7. Událost filesystem spolu s událostí static-network-up způsobí spuštění úlohy rc-sysinit. Zde přichází zpětná kompatibilita mezi staršími sysvinit a upstart…

9. rc-sysinit spustí příkaz telinit, který sdělí úroveň běhu systému.

10. Po získání úrovně běhu init spustí skripty, které začínají „S“ nebo „K“ (spouštění úloh, které mají „S“ v začátek jejich jména a zabití těch, kteří mají na začátku jména 'K') v adresáři /etc/rcX.d (kde 'X' je aktuální úroveň běhu) .

Tato malá sada událostí způsobí, že se systém spustí pokaždé, když jej zapnete. A toto událostní spouštění procesů je jediná věc, která je zodpovědná za vytvoření hierarchie.

Nyní je příčinou události další doplněk k výše uvedenému. Který proces způsobuje kterou událost, je také specifikováno ve stejném konfiguračním souboru procesu, jak je znázorněno níže na těchto řádcích:

Nahoře je část konfiguračního souboru procesu mountall. To ukazuje události, které vysílá. Název události je jeden za slovem „událost“. Událost může být buď ta, která je definována v konfiguračním souboru, jak je uvedeno výše, nebo to může být název procesu spolu s předponou ‚starting‘ , ‚started‘, ‚stopping‘ nebo ‚stoppped‘.

Takže zde definujeme dva pojmy:

1. Generátor událostí: Ten, který má v konfiguračním souboru řádek ‚emits xxx‘, kde xxx je název události, kterou vlastní nebo generuje.
2. Event Catcher: Ten, který má podmínku spuštění nebo zastavení jako xxx nebo který se spustí nebo zastaví při události vygenerované jedním z generátorů událostí.

Následuje tedy hierarchie a tedy i závislost mezi procesy:

Event generator (parent) -> Event catcher (child)

Přidání složitosti do hierarchie

Doposud jste museli pochopit, jak je hierarchie závislosti rodič-dítě mezi procesy stanovena mechanismem spouštění událostí pomocí jednoduchého zaváděcího mechanismu.

Nyní tato hierarchie nikdy není vztahem jeden k jednomu, který má pouze jednoho rodiče pro jedno dítě. V této hierarchii můžeme mít jednoho nebo více rodičů pro jedno dítě nebo jeden proces je rodičem více než jednoho dítěte. Jak se to provádí?? Odpověď spočívá v samotných konfiguračních souborech.

Tyto řádky jsou převzaty z procesu – síťování a zde se začátek za podmínek zdá příliš složitý, složený ze spousty událostí, jmenovitě – místní souborové systémy, udevtrigger, kontejner, úroveň běhu, síť.

Local-filesystems je emitován mountall, udevtrigger je název úlohy, kontejnerová událost je emitována kontejnerem-detect, událost runlevel emitovaná rc-sysinit a síťování je opět úloha.

V hierarchii je tedy síťování procesů potomkem mountall, udevtrigger a container-detect, protože nemůže pokračovat ve svém fungování (fungováním procesu jsou všechny řádky, které jsou definovány pod sekcemi skriptu nebo exec v konfiguračním souboru procesu) dokud výše uvedené procesy nevygenerují své události.
Podobně můžeme mít jeden proces rodičem mnoha, pokud je událost generovaná jedním procesem uložena do mezipaměti mnoha.

Rozlišení typů zaměstnání

Jak již bylo definováno výše, můžeme mít buď krátkodobé (nebo práce a zemřít) nebo dlouhodobé (nebo zůstaň a pracuj) zaměstnání, ale jak rozlišovat mezi jim??

Úlohy, které mají ve svých konfiguračních souborech zadané podmínky 'začít' a 'zastavit na' a mají ve svém souboru slovo 'úloha' konfigurační soubor jsou úlohy work-and-die, které se spouští na vygenerované události, provádějí svůj skript nebo sekci exec (při provádění blokují události, které je způsobily) a umírají poté, co uvolní ty události, které zablokovaly .

Úlohy, které ve svém konfiguračním souboru nemají podmínku zastavit, jsou úlohy s dlouhou životností nebo zůstaň a pracuj a nikdy nezemřou. Nyní lze pracovní místa pobytu a práce dále klasifikovat jako:

1. Ty, které nemají podmínku respawnu a mohou být zabity uživatelem root.
2. Ty, které mají ve svém konfiguračním souboru podmínku respawnu, a tak se po zabití restartují, pokud jejich práce nebyla dokončena.

Závěr

Každý proces v LINUXu je tedy na některých závislý a má na sobě závislé procesy a tento vztah je mnoho na mnoha a je specifikován u začínajícího systému spolu s dalšími detaily procesu.