Ako nakonfigurovať službu v Linuxe na automatické spustenie po reštarte alebo páde systému: 2. časť (Teoretické vysvetlenia)

V tejto druhej časti dvojdielneho návodu o konfigurácii Linux služieb na automatické spustenie po reštarte alebo páde systému podrobne prediskutujeme systém init. Môžete si pozrieť 1. časť série: Ako nakonfigurovať službu Linux na automatické spustenie po reštarte alebo páde systému: Praktické príklady tu.

Tento návod bude teoreticky náročnejší. Preto by ste ho mali použiť ako referenciu na hlbšie pochopenie toho, ako funguje systém init v systéme Linux. V prvej časti tohto návodu sme zdieľali niekoľko úryvkov kódu a spúšťacích skriptov, ktoré systém init číta pri spúšťaní. Použili sme tiež MySQL ako príklad, aby sme sa naučili, ako povoliť a zakázať automatické spúšťanie služby Linux po páde alebo reštarte. Ako ste sa dozvedeli v prvej časti tohto dvojdielneho návodu, v rôznych distribúciách Linuxu sa používajú tri systémy init: System V, Upstart a Systemd. Môžete si pozrieť prvú časť tohto návodu, aby ste pochopili distribúciu a verziu nakonfigurovanú na používanie konkrétneho systému init.

V tomto návode vysvetlíme kód, ktorý sme použili v prvej časti návodu. Podrobnejšie popíšeme príkazy a konfiguračné súbory, ktoré systém init používa. Začnime!

Požiadavky

V závere prvej časti tohto dvojdielneho návodu sme spomenuli, že by ste mali nechať bežať tri testovacie servery. Ak ste ich vymazali, môžete sa vrátiť a znova ich vytvoriť. Pomôže vám to sledovať návod. Tri testovacie servery, ktoré by ste mali mať, sú:

• Ubuntu 9.04 a staršie, alebo Debian 6 x64 (použijeme ho na demonštráciu systému init System V)
• Ubuntu 14.04 x64 (použijeme ho na demonštráciu Upstartu). Tu je návod, ako jednoducho nastaviť váš server Ubuntu.
• CentOS 7 x64 (použijeme ho na demonštráciu Systemd).

Na každom zo serverov, ktoré budete používať na spúšťanie príkazov, by ste mali mať používateľa s oprávneniami sudo. Tento návod na konfiguráciu súboru sudoers v Linuxe vás môže viesť.

Poznámka:  Príkazy v návode budú zasahovať do systémových služieb. Preto by ste ich nemali aplikovať na živom produkčnom serveri.

Runlevely

A runlevel je prevádzková úroveň, ktorá popisuje aktuálny stav systému Linux vo vzťahu k tomu, ktoré služby sú dostupné. Tento koncept pochádza zo System V init. Keď sa systém Linux spúšťa, inicializuje jadro, vstúpi do jedného runlevelu a spustí spúšťací skript spojený s týmto runlevelom. Pri spúšťaní môžete vykonať iba jeden runlevel.

Medzi ďalšie príklady runlevelov patrí stav vypnutia, režim reštartu, režim jedného používateľa atď. Každá úroveň určuje, ktoré služby sa majú v danom stave spustiť. Niektoré služby môžu bežať na viac ako jednej úrovni, zatiaľ čo iné nie.

Existuje sedem runlevelov: od 0 do 6. Nižšie je uvedená definícia týchto siedmich runlevelov:

• Runlevel 0: Vypnutie systému
• Runlevel 1: Režim jedného používateľa a záchranný režim
• Runlevely 2, 3, 4: Viacpoužívateľský a textový režim s povolenou sieťou
• Runlevel 5: Viacpoužívateľský, sieťový a grafický režim
• Runlevel 6: Reštart systému

Runlevely sa nemusia nevyhnutne vykonávať sekvenčne. Runlevely 2, 3 a 4 sa líšia v závislosti od distribúcie Linuxu, ktorú používate. V niektorých distribúciách môžete implementovať runlevel 4 a v iných nie. Keď ste povolili automatické spúšťanie služby, ako bolo vysvetlené v prvej časti, v skutočnosti ste ju pridali do runlevelu. V System V operačný systém začína s konkrétnym runlevelom a počas spúšťania sa pokúša spustiť všetky služby spojené s týmto runlevelom. Runlevely sú v Systemd ciele (targets), o ktorých budeme diskutovať v časti o Systemd.

Init a PID 1

Systém init je úplne prvý proces, ktorý sa spustí pri štarte systému Linux a načítaní jadra (Kernelu) do pamäte. Vykonáva rôzne úlohy vrátane určovania toho, ako sa načíta používateľský proces alebo systémová služba, v akom poradí a či sa má spustiť automaticky. V každej distribúcii Linuxu je každý proces identifikovaný ID procesu (PID) a init má PID 1. Je rodičom všetkých ostatných procesov, ktoré sa postupne spúšťajú pri štarte systému.

História initu

Systém init, ktorý sa nachádza v nedávnych distribúciách Linuxu, je vylepšením pôvodného. Najstaršie verzie distribúcií Linuxu používali System V init, ktorý sa podobne používal v systémoch Unix. Ako sa Linux vyvíjal, bol implementovaný init démon Upstart – vytvoril ho Ubuntu. Teraz (v čase písania tohto návodu, 2021) máme init démon Systemd – ten bol prvýkrát implementovaný distribúciou Fedora. Keďže systémy Linux sa naďalej vyvíjajú, môže sa objaviť novší systém init. V tomto návode budeme diskutovať o týchto troch: System V, Upstart a Systemd.

Nedávne verzie Linuxu sa predvolene dodávajú so systémom init Systemd. Ponechali si však aj ostatné staršie systémy init kvôli spätnej kompatibilite. Existujú rôzne implementácie System V, ktoré môžete použiť v iných variantoch Linuxu. Napríklad FreeBSD, variant UNIXu, používa BSD init. Staršie verzie Debianu používajú SysVinit. Oba pochádzajú zo System V.

Spôsob, akým každá verzia démona init spravuje služby, je odlišný. Vylepšenia pridané do každej verzie boli zamerané na robustný nástroj na správu služieb, ktorý by zvládol všetko, čo systém Linux potrebuje od služieb, zariadení, portov a iných prostriedkov. Bola potreba výkonného systému, ktorý by dokázal načítavať prostriedky paralelne a ktorý by sa dokázal elegantne zotaviť z pádu systému.

Spúšťacia sekvencia System V Init

System V využíva súbor inittab na uchovávanie inicializačných inštrukcií. Upstart uchováva súbor inittab kvôli spätnej kompatibilite. Tu je priebeh spúšťania System V:

• Systém init pochádza z binárneho súboru /sbin/init.
• Po načítaní systému init do pamäte prečíta svoj prvý súbor v /etc/inittab.
• Jeden zo záznamov v tomto súbore určuje úroveň spustenia (runlevel), do ktorej by sa mal počítač spustiť. Ak je napríklad hodnota úrovne spustenia špecifikovaná ako 5, Linux sa spustí vo viacpoužívateľskom, grafickom režime s povolenou sieťou (bežné v distribúciách určených pre desktopové použitie). Tu špecifikovaná úroveň spustenia je známa ako predvolená úroveň spustenia, pretože sa použije vždy.
• Potom sa systém init pozrie hlbšie do súboru /etc/inittab a prečíta, ktoré init skripty potrebuje spustiť pre danú úroveň spustenia.

Nájdením skriptov, ktoré sa majú spustiť pre danú úroveň spustenia, systém init zistí, ktoré služby potrebuje spustiť. V týchto init skriptoch zvyčajne konfigurujete správanie pri spúšťaní pre jednotlivé služby, rovnako ako sme konfigurovali službu MySQL v prvej časti tohto návodu.

Štruktúra init skriptov System V

V tejto časti sa podrobne pozrieme na init skripty. Konfiguračné súbory System V alebo init skripty sú to, čo riadi služby. Init skripty inicializujú službu, odtiaľ pochádza názov init skript.

Každá služba má svoj vlastný init skript. Napríklad init skript MySQL riadi MySQL server. Dodávatelia aplikácií poskytujú init skripty pre svoju konkrétnu aplikáciu, zatiaľ čo natívne služby Linuxu sa dodávajú s inštaláciou operačného systému. Keď vytvoríte vlastnú aplikáciu, môžete pre ňu vytvoriť aj vlastné init skripty.

Na spustenie služby, ako je MySQL server, sa jeho binárny program najprv načíta do pamäte. V závislosti od jeho konfigurácie môže program naďalej bežať na pozadí, aby prijímal pripojenia klientov. Init skript služby spracováva úlohu spustenia, zastavenia alebo opätovného načítania binárnej aplikácie. Init skripty v System V sú shell skripty. Iný názov pre ne sú rc (run command) skripty.

Adresárová štruktúra System V

Nadradeným adresárom pre init skripty je adresár /etc. Adresár /etc/init.d je skutočným adresárom pre init shell skripty. Tieto skripty sú symbolicky prepojené (symlinked) s adresármi rc.

V adresári /etc sa nachádza niekoľko adresárov rc, pričom každý má vo svojom názve číslo. Čísla predstavujú rôzne úrovne spustenia. Ak vypíšete obsah adresára, uvidíte názvy ako /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, atď.

Ak si pozriete obsah každého z adresárov rc, uvidíte súbory, ktoré začínajú na K alebo S vo svojom názve súboru, za ktorými nasledujú dve číslice. Tieto súbory obsahujú symbolické odkazy ukazujúce späť na skutočné init shell skripty skutočného programu. Písmená K a S sú skratky: K znamená Kill alebo Stop, zatiaľ čo S znamená Start. Dve číslice v názvoch súborov predstavujú poradie vykonávania. Ak vidíte súbor s názvom K05script_name, vykoná sa pred súborom s názvom K09script_name.

Startup

Pokračujme v sekvencii spúšťania a pozrime sa, ako sa volajú init skripty.

Skripty S a K nie sú volané priamo systémom init. Namiesto toho ich volá iný skript: /etc/init.d/rc skript. Súbor /etc/inittab inštruuje init démona, v akom runleveli by mal systém predvolene naštartovať. V závislosti od špecifikovaného runlevelu riadok v súbore /etc/inittab volá skript /etc/init.d/rc a odovzdáva predvolený runlevel ako parameter. Pomocou tohto parametra skript zavolá súbory v príslušnom adresári /etc/rcN.d, kde N označuje runlevel. Napríklad, ak server štartuje s runlevelom 5, príslušné súbory v adresári /etc/rc5.d budú zavolané.

Vo vnútri adresára rc sa všetky skripty K spúšťajú numericky s argumentom stop, zatiaľ čo všetky skripty S sa spúšťajú podobne s argumentom start. Príslušné skutočné init shell skripty pre program, na ktoré odkazujú symbolické odkazy v /etc/rcN.d, budú volané s parametrami stop a start v tomto poradí.

Zjednodušene povedané, kedykoľvek systém Linux vstúpi do určitého runlevelu alebo naň prepne, spustia sa určité skripty na zastavenie niektorých služieb, zatiaľ čo iné sa spustia na spustenie iných služieb. Tento proces zabezpečuje, že každý proces, ktorý by nemal bežať v danom stave Linuxu, sa zastaví, a každý proces, ktorý by mal bežať, sa spustí automaticky.

System V Automatically Starting

Keď povolíte automatické spúšťanie služby pri štarte, priamo upravujete správanie init. Napríklad, ak nakonfigurujete službu na automatické spúšťanie v runleveli 2, proces init vytvorí príslušné symbolické odkazy v adresári /etc/rc2.d. Aby sme vám to pomohli pochopiť, vysvetlíme si to na príklade.

System V Example

Aby sme vám uviedli praktický príklad, použijeme konfiguráciu služby MySQL z 1. časti. Prihláste sa preto do svojho Debian 6 VPS s vaším sudo/root používateľom pomocou ssh (alebo putty, ak ste na Windowse), a pokračujte nasledujúcimi krokmi.

Step 1: Open and examine the inittab file

Najprv zadajte nasledujúci príkaz na zobrazenie obsahu súboru inittab v termináli:

Obsah súboru by mal vyzerať približne takto:

Číslo 2 označuje runlevel, s ktorým systém štartuje. V tomto prípade je runlevel 2 predvolený, preto tento systém Debian naštartuje v runleveli 2 ako viacpoužívateľský, textový režim. Na potvrdenie môžete spustiť nasledujúci príkaz:

Zobrazí sa výstup podobný tomuto:

Step 2: Examining the rc directories

Ďalej, ak chcete vypísať adresáre rc, spustite nasledujúci príkaz:

Tu je snímka obrazovky s výstupom:

Ako sme už videli v súbore inittab, systém je nakonfigurovaný na spustenie v runleveli 2, preto sa skripty v /etc/rc2.d vykonajú pri štarte systému. Obsah tohto adresára môžete vypísať pomocou príkazu:

Ako môžete vidieť z výstupu, súbory sú len symbolické odkazy ukazujúce na skutočné súbory skriptov v /etc/init.d. Tu je úryvok z výstupu:

V tomto adresári nie sú žiadne skripty K, iba skripty S (štartovacie). Skripty spustia služby, ktoré sú tu prepojené, ako napríklad rsync. Môžete si tiež všimnúť službu mysql, ktorá je tu uvedená a o ktorej budeme hovoriť v ďalšej podtéme.

Step 3: Examining the Init Script

Keď sa nainštaluje služba kompatibilná so System V, vytvorí shell skript v adresári /etc/init.d. Dostupnosť shell skriptu MySQL môžete skontrolovať zadaním nasledujúceho príkazu:

Zobrazí sa nasledujúci výstup:

Súbor je pomerne veľký. Na zobrazenie jeho obsahu môžete zadať nasledujúci príkaz:

Krok 4: Použitie chkconfig alebo sysv-rc-conf

Chkconfig je príkaz, ktorý môžete použiť v distribúciách založených na RHEL, ako je CentOS na povolenie alebo zakázanie služieb kompatibilných so System V. Môžete ho použiť aj na zobrazenie zoznamu nainštalovaných služieb a ich príslušných úrovní spustenia. Tu je príkaz na to (funguje v systéme CentOS):

V distribúciách Debian takýto nástroj natívne neexistuje. Nástroj update-rc.d v systémoch Debian iba inštaluje a odstraňuje služby z úrovní spustenia. K dispozícii je vlastný nástroj, ktorý môžete použiť na prenesenie funkčnosti chkconfig do systémov Debian. Na jeho inštaláciu zadajte nasledujúci príkaz:

Po inštalácii môžete spustiť nasledujúci príkaz na zobrazenie správania úrovní spustenia pre rôzne služby:

Výstup tohto príkazu je naformátovaný do tabuľky, ktorá zobrazuje názov služby vľavo a úroveň spustenia, pod ktorou služba beží:

Znak X označuje úroveň spustenia, pod ktorou bude služba bežať. Tento nástroj vám umožňuje zakázať alebo povoliť službu pre úroveň spustenia pomocou šípok a medzerníka. Pre ukončenie nástroja stlačte Q.

Krok 5: Testovanie správania MySQL pri spúšťaní počas bootovania systému

Na snímke obrazovky vyššie môžete vidieť, že služba mysql je povolená na úrovniach spustenia 2,3,4,5. Službu MySQL môžete zakázať pomocou nasledujúceho príkazu:

Výstup vyzerá takto. Všimnite si, že služba sa zastavila pre všetky úrovne spustenia:

Spustite príkaz nižšie, aby ste videli obsah adresára:

Pozrite si riadok mysql vo výstupe nižšie:

Výstup ukazuje, že symbolický odkaz sa zmenil na K, čo znamená Kill (zastaviť). Preto sa MySQL predvolene nespustí automaticky na úrovni spustenia 2. Kedykoľvek povolíte alebo zakážete službu v System V, stane sa toto. Pokiaľ v adresári predvolenej úrovne spustenia pre službu existuje skript S (štart), démon init túto službu spustí počas bootovania systému.

Ak chcete službu znova povoliť, zadajte nasledujúci príkaz:

Krok 6: Testovanie správania MySQL pri spúšťaní po páde systému

V tejto časti si povieme, ako System V rieši pády služieb. Tieto znalosti môžete použiť na konfiguráciu správania vašich vlastných služieb po páde.

V prvej časti tohto návodu sme vykonali zmenu v súbore /etc/inittab, aby sme umožnili automatické spustenie MySQL po páde. Na povolenie tohto správania sme pridali nasledujúci riadok:

Toto správanie môžeme overiť vykonaním niekoľkých testov. Najprv reštartujte svoj VPS zadaním nasledujúceho príkazu:

Po reštarte skontrolujte, s akými ID procesov bežia mysql_safe a mysqld. Na získanie ID procesov zadajte nasledujúci príkaz:

Výstup, ktorý sme dostali, bol:

Poznačte si ID procesov. V našom prípade to boli 1836 a 186338. Teraz nasimulujte pád ukončením procesu pomocou prepínača -9 zadaním nasledujúceho príkazu. Nezabudnite ich nahradiť vašimi ID procesov:

Po niekoľkých minútach skontrolujte stav MySQL spustením nasledujúceho príkazu:

Výstup indikuje, že MySQL beží, čo znamená, že po simulovanom páde bolo znova spustené. Ak znova spustíte príkaz ps -ef | grep mysql, zistíte, že procesy mysqld_safe aj mysqld bežia, aj keď s novými ID.

Môžete sa pokúsiť ukončiť procesy viackrát a po niekoľkých minútach sa znova spustia. Toto správanie umožňuje riadok, ktorý sme pridali do súboru /etc/inittab. Takto nakonfigurujete služby na automatické reštartovanie po páde v System V. Ak chcete znova vidieť syntax, pozrite si 1. časť tohto návodu.

Niektoré vlastné služby môžu obsahovať chyby a po viacerých pokusoch sa nemusia znova spustiť. Démon init sa pokúsi službu znova spustiť, ale ak zlyhá viac ako desaťkrát v priebehu dvoch minút, systém Linux službu zakáže až na 5 minút. Pomáha to udržiavať systém stabilný a zabezpečuje, že sa systémové prostriedky neplytvajú na padajúce služby. Je dobré skontrolovať systémové protokoly a identifikovať problémy s vašimi vlastnými aplikáciami, ktoré je potrebné opraviť.

Úvod do Upstart

Inicializačný systém System V bol pre distribúcie Linuxu dlho kľúčový. Avšak, ako to už s technológiami býva, neustále napreduje. Ekosystém Linuxu nesmierne narástol vďaka podpore komunity open-source. System V načítava úlohy a služby serializovaným spôsobom, čo prináša zložitosť a spotrebúva čas. Okrem toho zavedenie moderných pripojiteľných pamäťových médií, pre ktoré System V nebol navrhnutý, vyvolalo potrebu iného inicializačného systému.

Vývojári v Ubuntu začali pracovať na inom inicializačnom systéme. Tento init systém bol navrhnutý tak, aby zvládal rýchlejšie načítanie operačného systému, zabezpečil bezproblémové vyčistenie spadnutých služieb, udržiaval predvídateľné závislosti medzi systémovými službami a zohľadňoval pripojiteľné pamäťové médiá. Narodil sa démon Upstart.

Upstart init má oproti System V init niekoľko výhod v nasledujúcich oblastiach:

• Upstart nenačítava služby sériovo ako System V, čím skracuje čas spúšťania systému.
• Je navrhnutý tak, aby lepšie zvládal spadnuté služby s bezproblémovým vyčistením a opätovným spustením služby.
• Upstart využíva flexibilný systém udalostí na prispôsobenie správy služieb v rôznych stavoch.
• Tento init sa vyhýba zložitým shell skriptom na načítanie a správu služieb ako v System V. Upstart používa jednoduché konfiguračné súbory, ktoré sa dajú ľahko pochopiť a upraviť.
• Upstart bol vytvorený s ohľadom na spätnú kompatibilitu. Skript /etc/init.d/rc stále beží na správu natívnych služieb System V.
• Vyhýba sa udržiavaniu nadbytočných symbolických odkazov, ktoré všetky ukazujú na rovnaký skript.

Udalosti Upstart

Upstart je založený na udalostiach, čo umožňuje priradiť k rovnakej službe viacero udalostí. Táto architektúra založená na udalostiach zabezpečuje flexibilnú správu služieb. Každá udalosť môže volať shell skript špecifický pre danú udalosť.

Medzi udalosti Upstart patria:

• Starting
• Started
• Stopping
• Stopped

Medzi udalosťami môže byť služba v rôznych stavoch, okrem iného vrátane:

• Waiting
• Pre-start
• Starting
• Post-start
• Running
• Pre-stop
• Stopping
• Post-stop

Upstart init môže byť nakonfigurovaný tak, aby vykonal akcie pre každý z týchto stavov, z čoho vyplýva jeho flexibilný dizajn.

Spúšťacia sekvencia Upstart Init

Upstart init spúšťa skript /etc/init.d/rc pri spúšťaní, rovnako ako System V. Tento skript normálne spúšťa akékoľvek init skripty System V, aby sa zabezpečila spätná kompatibilita.

Konfiguračné súbory Upstart sa nachádzajú v adresári /etc/init, takže tam predvolene hľadá a vykonáva príkazy shellu nájdené v konfiguračných súboroch v tomto adresári.

Konfiguračné súbory Upstart

Upstart init používa na riadenie služieb konfiguračné súbory služieb, na rozdiel od bash skriptov používaných v System V. Štandard pomenovania týchto konfiguračných súborov služieb je service_name.conf.

Súbory obsahujú čistý text rozdelený do rôznych sekcií nazývaných stanzas (bloky). Každý blok popisuje iný stav služby a jej správanie. Rôzne bloky riadia rôzne udalosti služby. Napríklad waiting, pre-start, start, pre-stop, stopping atď.

Blok obsahuje príkazy shellu, čo umožňuje spustiť niekoľko akcií pre každú udalosť pre každú službu. Okrem toho každý konfiguračný súbor služby špecifikuje nasledujúce dve veci:

• Na ktorých úrovniach spustenia (runlevels) by sa mala služba spustiť a zastaviť.
• Či sa má služba v prípade pádu reštartovať (respawn).

Adresárová štruktúra Upstart

Konfiguračné súbory služieb Upstart sa nachádzajú v adresári /etc/init . Nepleťte si to s  /etc/init.d.

Príklad Upstart

V tomto príklade uvidíme, ako Upstart narába so službou počas spúšťania systému a v prípade pádu. Podrobnejšie si vysvetlíme praktické príklady uvedené v prvej časti tohto návodu.

Krok 1: Prihláste sa na server Ubuntu 14.0.4

Najprv na testovanie Upstart použijeme druhý VPS, ten, na ktorom beží Ubuntu 14.0.4. Je to preto, že táto distribúcia Linuxu implementuje Upstart natívne. Ak používate Windows, použite ssh alebo putty. Musíte sa prihlásiť pod používateľom s oprávneniami root alebo sudo. Mám používateľa s názvom hackins, takže by som sa prihlásil takto:

Nahraďte svojím root/sudo používateľom a verejnou IP adresou servera. Potom stlačte enter a zadajte heslo alebo prístupovú frázu.

Krok 2: Preskúmajte adresáre init a rc

Konfiguračné súbory Upstart sú uložené v adresári /etc/init. Je to adresár, ktorý budete používať pri vytváraní nových konfiguračných súborov služieb.

Ak chcete zobraziť zoznam názvov konfiguračných súborov v adresári /etc/init, vykonajte nasledujúci príkaz:

Ako uvidíte z výstupu vyššie uvedeného príkazu, pod Upstart beží mnoho služieb. Stlačením klávesu Q ukončíte program less.

Ak spustíte nasledujúci príkaz na zobrazenie konfiguračných súborov služieb pre System V v adresári rc, uvidíte ich len niekoľko:

Krok 3: Preskúmajte súbor Upstart

V prvej časti tohto návodu sme použili súbor mysql.conf na oboznámenie sa s konfiguráciou servera. Aby sme si rozšírili vedomosti, použime inú konfiguráciu. Konfiguračný súbor cron je dobrým kandidátom. Zadajte nasledujúci príkaz na otvorenie súboru:

Mali by ste dostať výstup podobný snímke obrazovky nižšie:

Skript je pomerne jednoduchý. Všimnite si nasledujúce dôležité polia: start on, stop on, fork, a respawn. Poďme si definovať, čo tieto direktívy robia:

• start on inštruuje Ubuntu, aby spustilo démona cron, keď systém prejde do úrovní spustenia 2, 3, 4 alebo 5. Nebude bežať na iných úrovniach spustenia, ktoré tu nie sú uvedené, t. j. 0, 1 alebo 6.
• stop on inštruuje Ubuntu, aby zastavilo bežiaceho démona. V tomto prípade je tu však výkričník (!), ktorý je znakom negácie. Skript by sa nemal zastaviť na úrovniach spustenia po výkričníku: 2,3,4,5.
• fork direktíva inštruuje Upstart, aby odpojil proces od konzoly a nechal ho bežať na pozadí.
• respawn direktíva inštruuje systém, aby automaticky spustil cron , ak z akéhokoľvek dôvodu spadne.

Stlačením klávesov Ctrl X ukončíte editor bez toho, aby ste čokoľvek napísali.

Ostatné konfiguračné súbory Upstart majú rovnakú štruktúru s blokmi pre start, stop a respawn. Niektoré konfiguračné súbory môžu mať ďalšie bloky skriptov pre pre-start, pre-stop, post-start a ďalšie. Tieto bloky kódu hovoria systému, čo má vykonať, keď je proces v ktoromkoľvek z definovaných stavov.

Krok 4: Otestujte správanie pri spúšťaní služby MySQL po zavedení systému

MySQL je predvolene nastavený na automatické spustenie po štarte systému. Pokúsime sa ho zakázať a uvidíme, ako sa bude správať. V systéme Upstart je možné službu zakázať vytvorením súboru s názvom service_name.override v adresári /etc/init/. Obsah súboru je len jedno slovo: manual.

Pozrime sa, ako môžeme tento príkaz použiť na zakázanie služby MySQL. Zadajte nasledujúci príkaz na otvorenie súboru v editore nano:

Do otvoreného súboru pridajte nasledujúci riadok:

Uložte zmeny stlačením Ctrl + O, potom stlačte Enter. Ukončite editor stlačením Ctrl + X. Spustite nasledujúci príkaz na reštartovanie servera:

Počkajte niekoľko minút a potom sa znova prihláste. Po opätovnom prihlásení otestujte stav služby MySQL zadaním nasledujúceho príkazu:

Výstup bude indikovať, že služba nebeží:

To znamená, že MySQL sa po štarte systému nespustil automaticky. Ďalej otvorte konfiguračný súbor MySQL a skontrolujte, či sa inštrukcia start zmenila:

Výstup bude indikovať, že sa nič nezmenilo:

To znamená, že ak sa vaša služba nespúšťa automaticky a skontrolujete iba konfiguračný súbor služby (service_name.conf), nemusíte chybu nájsť. Mali by ste tiež skontrolovať existenciu súboru service_name.override v adresári.

Zadaním nasledujúceho príkazu vymažte súbor override a znova povoľte službu MySQL. Potom reštartujte server:

Po nabehnutí servera znova otestujte stav služby MySQL:

Malo by sa zobraziť, že služba MySQL sa spustila automaticky.

Krok 5: Testovanie správania pri spúšťaní služby MySQL po páde systému

Predvolene sa služba MySQL po páde automaticky reštartuje. Ak chcete toto správanie zastaviť, upravíme súbor mysql.conf . Zadajte nasledujúci príkaz na otvorenie súboru v editore nano:

Nájdite riadky s inštrukciou respawn a zakomentujte ich, ako je znázornené nižšie pomocou #:

Spustite nasledujúce príkazy na reštartovanie služby:

Na zastavenie a spustenie služby sme použili vyššie uvedené príkazy, pretože použitie initctl restart alebo initctl reload by tu nefungovalo. Keď spustíte príkaz na spustenie služby MySQL, na výstupe sa zobrazí PID pre MySQL ako:

Naše PID bolo 1439. Ďalej si poznačte, čo ste dostali pri spustení príkazu, použijeme to v nasledujúcom kroku. Ak chcete simulovať pád, ukončite proces MySQL pomocou nasledujúceho príkazu, nezabudnite nahradiť svoje PID, ako je vysvetlené vyššie:

Ak chcete skontrolovať, či sa MySQL po páde reštartoval, počkajte niekoľko minút a potom zadajte nasledujúci príkaz:

Výstup bude indikovať, že MySQL je zastavený:

Skúste skontrolovať stav ešte niekoľkokrát, aby ste zistili, či došlo k nejakej zmene. Všimnete si, že MySQL zostane zastavený. Je to preto, že konfiguračný súbor služby neobsahuje inštrukcie respawn (tie, ktoré sme zakomentovali). Viac vysvetlenia o inštrukcii respawn nájdete v 1. časti tohto návodu.

Prečo sme vám ukázali, ako zakázať automatické reštartovanie služieb po spustení alebo páde systému? Je to hlavne na účely riešenia problémov. Ak sa napríklad vaša služba spustí a neustále padá, možno ju budete chcieť zakázať, aby ste mohli problém vyriešiť a zároveň udržať systém stabilný. Môžete tiež zabrániť automatickému reštartovaniu niektorých starých konfigurácií služieb, ak prejdete na novú distribúciu Linuxu, ktorá natívne obsahuje systemd, o ktorom hovoríme v nasledujúcej časti.

Úvod do Systemd

Systemd je najnovší init systém, ktorý sa nachádza v najnovších distribúciách Linuxu. Obsahuje mnoho komponentov, ktoré tvoria moderný systém Linux.

Systemd spravuje nielen služby, ale aj celý systém Linux. V tejto časti sa zameriame na to, ako systemd riadi správanie služieb po spustení alebo páde systému.

Systemd je spätne kompatibilný s init skriptami a príkazmi System V. Preto, ak máte nejaké služby nakonfigurované pre System V, pobežia aj pod Systemd. Väčšina administratívnych príkazov Upstart a System V bola upravená tak, aby fungovala so Systemd. Systemd sa pri spúšťaní premenuje na init. Existuje súbor /sbin/init, ktorý je symbolickým odkazom na /bin/systemd.

Konfiguračné súbory Systemd: Súbory jednotiek

Konfigurácia Systemd pozostáva zo súborov jednotiek. Každý súbor jednotky predstavuje systémový prostriedok. Zatiaľ čo ostatné dva init systémy (t. j. System V a Upstart) boli zodpovedné za správu služieb systému Linux, Systemd spravuje nielen démony služieb, ale aj iné typy systémových prostriedkov, ako sú cesty k operačnému systému zariadení, sockety, body pripojenia atď. Súbory jednotiek ukladajú informácie o prostriedku.

Každý súbor jednotky predstavuje konkrétny systémový prostriedok s formátom názvu service_name.unit_type. To znamená, že nájdete súbory ako home.mount, dbus.service, sshd.socket atď. Súbory jednotiek sú jednoduché textové súbory s deklaratívnou syntaxou, ktorú je ľahké pochopiť a upraviť.

Adresárová štruktúra

Hlavné umiestnenie natívnych súborov jednotiek je v adresári /lib/systemd/system/. Súbory jednotiek, ktoré vytvoríte vy alebo ktoré na mieru vytvorili správcovia systému, a iné upravené natívne súbory jednotiek sú uložené v adresári /etc/systemd/system.

Ak súbor jednotky s rovnakým názvom existuje v adresároch /lib/systemd/system/ aj /etc/systemd/system, systemd použije ten, ktorý sa nachádza v adresári /etc.

Keď povolíte spustenie služby pri štarte systému alebo pri akomkoľvek inom cieli/úrovni spustenia, vytvorí sa symbolický odkaz pre tento súbor jednotky služby v príslušných adresároch v /etc/systemd/system. Súbory jednotiek v adresári /etc/systemd/system sú len symbolické odkazy na súbory s podobným názvom v adresári /lib/systemd/system.

Sekvencia spustenia Systemd: Cieľové jednotky

Cieľové jednotky sú jedinečné typy súborov jednotiek, ktoré majú zvyčajne príponu .target. Cieľové jednotky sa líšia od iných typov súborov jednotiek tým, že nepredstavujú jeden konkrétny prostriedok. Namiesto toho predstavujú stav celého systému v danom čase.

Na dosiahnutie tohto cieľa cieľové jednotky zoskupujú a spúšťajú viacero súborov jednotiek, ktoré sú súčasťou konkrétneho stavu. Hoci ciele Systemd a úrovne spustenia System V možno voľne porovnávať, nie sú rovnaké. Súbor cieľovej jednotky má namiesto čísla názov. Nájdete tu napríklad niečo ako multi-user.target namiesto runlevel 3 alebo reboot.target namiesto runlevel 6. Systém Linux sa môže spustiť s multi-user.target. V tomto prípade to v podstate privádza server do úrovne spustenia 2, 3 alebo 4, čo spúšťa systém v textovom režime pre viacerých používateľov s povolenou sieťou.

Rozdiel je v tom, ako privádza server do tejto úrovne. System V spúšťa služby sekvenčne. Na druhej strane, pri spúšťaní systému systemd kontroluje, či existujú iné služby alebo prostriedky, a určuje poradie ich načítania.

Ďalším rozdielom medzi cieľovými jednotkami systemd a úrovňami spustenia System V je, že distribúcia Linuxu používajúca System V bude existovať iba v jednej úrovni spustenia. Ak úroveň spustenia zmeníte, jednoducho sa prepne do tejto novej úrovne a bude v nej existovať. Na druhej strane, súbory cieľových jednotiek môžu byť inkluzívne. Aktivácia cieľovej jednotky navyše zabezpečuje, že sa ako jej súčasť načítajú aj ďalšie cieľové jednotky. Ak napríklad spustíte systém Linux s grafickým používateľským rozhraním, bude mať aktivovaný graphical.target aktivovaný. To zasa automaticky zabezpečí, že multi-user.target sa tiež načíta a aktivuje.

Tu je tabuľka porovnávajúca úrovne spustenia (runlevels) a cieľové jednotky (targets).

Úroveň spustenia (System V)	Cieľové jednotky (systemd)
runlevel 0	poweroff.target
runlevel 1	rescue.target
runlevel 2,3,4	multi-user.target
runlevel 5	graphical.target
runlevel 6	reboot.target

Systemd default.target

V systemd je default.target ekvivalentom predvolenej úrovne spustenia v System V. Videli sme, že predvolená úroveň spustenia v System V bola definovaná v súbore inittab. V systemd máme súbor default.target. Súbor predvoleného cieľa je uložený v adresári /etc/systemd/system. Odkazuje symbolickým odkazom (symlink) na jeden zo súborov cieľových jednotiek v /lib/systemd/system. Zmena predvoleného cieľa jednoducho znamená opätovné vytvorenie symbolického odkazu a úpravu úrovne spustenia systému.

V System V súbor inittab určoval, v ktorom adresári Linux nájde inicializačné skripty (init scripts). Mohol to byť ktorýkoľvek z adresárov rc, ako bolo vysvetlené predtým. Na druhej strane, predvolený cieľ systemd určuje jednotky prostriedkov, ktoré sa majú načítať pri spúšťaní systému. Načítajú sa všetky definované jednotky. Nie všetky sa však načítavajú paralelne a nie všetky sa načítavajú sekvenčne. Načítanie jednotky prostriedku závisí od iných prostriedkov, ktoré chce (wants) alebo vyžaduje (requires).

Závislosti Systemd: Wants a Requires

V tejto časti si povieme, ako Systemd spracováva závislosti. Videli sme, že s Upstartom je pri použití konfiguračných súborov možné paralelné načítanie služieb. Diskutovali sme aj o tom, ako System V používa úrovne spustenia na určenie toho, ktorá služba sa má automaticky spustiť alebo či má počkať, kým sa nespustí iná služba alebo prostriedok. Podobne môžu byť služby Systemd nakonfigurované tak, aby sa načítali v jednom alebo viacerých cieľoch, alebo aby počkali, kým sa nespustí iná služba alebo prostriedok.

V Systemd sa súbor jednotky, ktorý vyžaduje (requires) inú jednotku, nespustí, kým sa vyžadovaná jednotka nenačíta a neaktivuje. Ak sa vyžadovaná jednotka nenačíta, kým je prvá jednotka aktívna, prvá jednotka sa zastaví.

Toto správanie zaisťuje stabilitu systému. Služba, ktorá vyžaduje (requires) konkrétny prostriedok (napríklad port), aby bol dostupný a aktívny, tak môže byť prinútená čakať, kým bude tento prostriedok dostupný (t. j. port sa otvorí).

Naopak, jednotka, ktorá chce (wants) inú jednotku, neukladá takéto obmedzenia. Nezastaví sa, ak sa požadovaná jednotka zastaví, kým je volajúca jednotka stále aktívna. Príkladom sú niektoré nepodstatné služby v režime graphical-target.

Príklad Systemd

Pozrime sa, ako môžeme nakonfigurovať správanie služby pod systemd.

Krok 1: Prihláste sa do svojej inštancie VPS

Ako reálnu službu budeme používať MySQL a ako server CentOS 7. Ak chcete prejsť jednotlivými krokmi prakticky a pochopiť koncepty, prihláste sa do svojho VPS s CentOS 7 alebo si ho vytvorte na CloudSigma. Pre túto časť je vhodné VPS s distribúciou CentOS 7, Debian 7 alebo 8, prípadne Ubuntu 15 alebo novšou, keďže všetky sa dodávajú so systemd. Prihláste sa pomocou príkazu ssh, alebo ak používate Windows, použite PuTTY:

Krok 2: Preskúmajte súbor default.target a závislosti

Spúšťacia sekvencia Systemd nasleduje dlhý reťazec závislostí, o ktorých budeme podrobne diskutovať v tejto časti.

• default.target

Súbor default.target riadi služby, ktoré sa spúšťajú počas bežného spúšťania systému. Súbor predvolenej cieľovej jednotky môžete vypísať pomocou nasledujúceho príkazu:

Výstup vyzerá podobne ako na snímke obrazovky nižšie:

Snímka obrazovky ukazuje, že predvolený cieľ odkazuje symbolickým odkazom (symlink) na súbor multi-user.target v /lib/systemd/system/ adresár. To znamená, že systém sa predvolene spustí pod multi-user.target, čo je ekvivalent pre runlevel 3.

• multi-user.target.wants

Ak chcete zobraziť všetky služby, ktoré súbor multi-user.target vyžaduje, zadajte nasledujúci príkaz:

Výstup obsahuje veľa riadkov, tu je ukážka:

Ako ukazuje výstup, ide o symbolické odkazy ukazujúce na skutočné súbory jednotiek v /lib/systemd/system/ adresári. Zvýraznili sme mysqld.service, aby sme vás upozornili, že je tiež súčasťou multi-user.target. Ak chcete overiť, či je konkrétna služba nakonfigurovaná na spustenie, môžete upraviť príkaz pre daný súbor. Napríklad môžeme filtrovať výstupy na vyhľadanie démona mysql alebo cron pomocou nasledujúcich príkazov:

Výstup zobrazí:

Ak chcete filtrovať výsledok pre démona cron, zadajte nasledujúci príkaz:

Výstup zobrazí:

Okrem multi-user.target, existujú aj iné rôzne typy cieľov, napr. system-update.target alebo basic.target.

Zadaním nasledujúceho príkazu zobrazíte, od ktorých cieľov závisí multi-user target:

Výstup zobrazuje:

To znamená, že basic-target sa musí načítať ako prvý, aby sa systém spustil v multi-user.target režime.

• basic-target

Zadaním nasledujúceho príkazu zobrazíte, aké ďalšie ciele vyžaduje basic.target:

Výstup zobrazí:

• sysinit.target

Spustením nasledujúceho príkazu môžete zistiť, či existujú nejaké vyžadované cieľové jednotky pre sysinit.target. Syntaxia príkazu je rovnaká. Môžete ju priebežne upravovať, aby ste videli, ktoré cieľové jednotky sú vyžadované inou cieľovou jednotkou. Tu je príkaz:

Výstup ukáže, že pre sysinit.target neexistujú žiadne vyžadované jednotky. Môžeme skontrolovať, či sú pre vyžadované jednotkou sysinit.target iné služby a cieľové jednotky pomocou nasledujúceho príkazu:

Výstup zobrazuje dlhý zoznam služieb a cieľových jednotiek vyžadovaných jednotkou sysinit.target. Časť výstupu si môžete pozrieť nižšie:

Počas inicializácie systému so system4 sa systém nezastaví len v jednom cieľovom stave. Namiesto toho načítava služby závislým spôsobom, ako prechádza z jedného cieľa do druhého.

Krok 3: Preskúmanie súboru jednotky (Unit File)

Pozrime sa, ako vyzerá súbor jednotky. V prvej časti tohto návodu sme použili súbor jednotky služby MySQL a použijeme ho znova. Môžeme sa však pozrieť aj na iný súbor jednotky služby – súbor jednotky sshd. Zadaním nasledujúceho príkazu otvorte konfiguračný súbor sshd:

Nižšie je snímka obrazovky zobrazujúca riadky v súbore:

Ako môžete vidieť, bloky kódu načrtnuté v súbore uľahčujú jeho pochopenie a úpravu v prípade potreby. Nižšie sú uvedené niektoré dôležité direktívy, ktorým je potrebné porozumieť:

• After – klauzula After hovorí systému, aby službu načítal až po načítaní špecifikovaných cieľov a služieb. V tomto prípade sa služba SSHD načíta po načítaní sieťového cieľa a služby keygen.
• Wants – klauzula Wants ukazuje, ktoré cieľové jednotky vyžadujú túto službu. V tomto prípade služba ssh-keygen.service vyžaduje sshd.service. Ak však sshd zlyhá alebo spadne, nevypne to službu ssh-keygen.service.

Stlačením Ctrl + X zatvorte editor.

Krok 4: Otestovanie správania pri spúšťaní služby MySQL pri štarte systému

V tejto časti vám ukážeme, ako môžete zmeniť a otestovať správanie služby MySQL pri štarte systému. V predchádzajúcej časti sme videli, že služba mysqld.service je vyžadovaná jednotkou multi-user.target. Preto sa automaticky spustí pri štarte systému.

Službu môžete zakázať spustením nasledujúceho príkazu:

Spustenie príkazu ukáže, že symbolický odkaz mysql bol odstránený z adresára /etc/systemd/system/multi-user.target.wants/ directory. Ak to chcete otestovať, spustite nasledujúci príkaz, aby ste zistili, či je MySQL stále vyžadovaná jednotkou multi-user.target:

Príkaz nevráti nič. Ak sa pokúsite reštartovať server a skontrolovať stav MySQL, nebude spustený, čo znamená, že sa nespustil automaticky pri štarte.

Teraz znova povoľte službu pomocou príkazu:

Výstup zobrazí symbolický odkaz. Ak reštartujete server, MySQL by sa malo spustiť automaticky. Povolenie služby Systemd vytvorí symbolický odkaz v adresári wants predvoleného cieľa. Zakázanie služby Systemd odstráni symbolický odkaz z adresára wants.

Krok 5: Otestovanie správania pri spúšťaní služby MySQL po páde služby

V predvolenom nastavení sa služba MySQL v prípade pádu automaticky reštartuje. Toto správanie môžeme zakázať v konfiguračnom súbore Systemd pre MySQL. Najprv sa pozrime na tento súbor. Zadajte nasledujúci príkaz na otvorenie súboru:

Snímka obrazovky nižšie zobrazuje výstup:

Hodnota direktívy Restart je nastavená na on-failure. To znamená, že služba MySQL sa reštartuje po nečistých návratových kódoch, vypršaní časového limitu alebo nečistých signáloch. Nižšie je tabuľka zobrazujúca niektoré parametre reštartu z manuálovej stránky.

Nastavenia reštartu/Príčiny ukončenia	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
Čistý návratový kód alebo signál		X	X
Nečistý návratový kód		X		X
Nečistý signál		X		X	X	X
Časový limit		X		X	X
Watchdog		X		X	X		X

Dve dôležité direktívy v unit súbore Systemd sú Restart a RestartSec. Riadia správanie služby pri páde. Restart určuje, kedy sa má služba reštartovať, a RestartSec určuje, ako dlho má čakať pred reštartovaním po páde. Ak chcete zakázať správanie reštartu, zakomentujte direktívu Restart pridaním znaku # na začiatok riadku, ako je znázornené:

Teraz znova načítajte systémového démona a potom znova načítajte službu mysqld pomocou nasledujúcich príkazov:

Ďalej spustite nasledujúci príkaz na vyhľadanie hlavného PID služby MySQL:

Hlavné PID pre náš test bolo 23809. Poznačte si svoje, aby ste ho mohli použiť v nasledujúcom príkaze. Pomocou príkazu kill -9 nasimulujte pád ukončením procesu. Nezabudnite tiež nahradiť číslo procesu tým, ktoré ste získali vo vašom teste:

Ak spustíte príkaz, ktorý kontroluje stav MySQL, zistíte, že nie je aktívny a nepodarilo sa ho reštartovať:

Zostane v chybovom stave, pokiaľ bude direktíva Restart zakomentovaná v konfiguračnom súbore mysqld.service. Týmto sa emuluje pád, kedy sa služba zastaví a znova sa nespustí.

Ak chcete službu znova povoliť, môžete upraviť konfiguračný súbor mysqld.service, odkomentovať direktívu Restart, potom ho uložiť a zatvoriť. Podobne ako predtým, znova načítajte démona a reštartujte službu. Tým sa služba vráti do pôvodnej konfigurácie a teraz sa po páde môže automaticky spustiť. To je nakoniec všetko k nastaveniu automatického spúšťania služby po páde. Ak chcete nakonfigurovať služby tak, aby sa po páde automaticky spúšťali, stačí pridať direktívu Restart (a ak chcete, môžete pridať aj direktívu RestartSec) pod sekciu [Service] unit súboru služby.

Záver

V tomto návode sme si vysvetlili, ako Linux narába so službami počas spúšťania alebo po páde. Aby sme pochopili proces inicializácie systému Linux, prebrali sme tri init systémy, ktoré Linux používa: System V, Upstart a Systemd. Diskutovali sme o ich vývoji a o tom, ako každý init proces funguje v súvislosti s automatickým spúšťaním služby po reštarte systému alebo páde.

Keďže sa init démoni aj distribúcie Linuxu postupom času vyvíjali, nezabudnite skontrolovať verziu distribúcie Linuxu, ktorú používate, aby ste vedeli, ktorého init démona váš systém natívne podporuje.

Natívne aplikácie pre Linux a väčšina aplikácií tretích strán sa po spustení alebo páde systému už automaticky spúšťajú, takže nebudete musieť nič robiť. Poznatky v tomto návode sú kľúčové, keď konfigurujete správanie pri spúšťaní a opätovnom spúšťaní svojich vlastných služieb, alebo pri riešení problémov so službami, ktoré neustále padajú.

Príjemnú prácu s počítačom!