Kako konfigurirati Linux servis za automatsko pokretanje nakon ponovnog pokretanja ili rušenja sustava: 2. dio (Teorijska objašnjenja)

U ovom drugom dijelu dvodijelnog vodiča o konfiguriranju Linux usluga za automatsko pokretanje nakon ponovnog pokretanja ili rušenja sustava, detaljno ćemo raspraviti o init sustavu. Možete se referirati na 1. dio serije: Kako konfigurirati Linux uslugu za automatsko pokretanje nakon ponovnog pokretanja ili rušenja sustava: Praktični primjeri ovdje.

Trenutačni vodič bit će bogat teorijom. Stoga biste ga trebali koristiti kao referencu za dublje razumijevanje rada init sustava u Linuxu. U prvom dijelu ovog vodiča podijelili smo neke isječke koda i skripte za pokretanje koje init sustav čita prilikom pokretanja. Također smo koristili MySQL kao primjer kako biste naučili kako omogućiti i onemogućiti automatsko pokretanje Linux usluge nakon rušenja ili ponovnog pokretanja. Kao što ste naučili u prvom dijelu ovog dvodijelnog vodiča, postoje tri init sustava koja se koriste u različitim distribucijama Linuxa: System V, Upstart i Systemd. Možete se referirati na prvi dio ovog vodiča kako biste razumjeli koja je distribucija i verzija konfigurirana za korištenje određenog init sustava.

U ovom vodiču objasnit ćemo kod koji smo koristili u prvom dijelu vodiča. Detaljnije ćemo opisati naredbe i konfiguracijske datoteke koje init sustav koristi. Počnimo!

Preduvjeti

U zaključku prvog dijela ovog dvodijelnog vodiča spomenuli smo da biste trebali ostaviti tri testna poslužitelja aktivna. Ako ste ih izbrisali, možete se vratiti i ponovno ih izraditi. To će vam pomoći da pratite vodič. Tri testna poslužitelja koja biste trebali imati su:

• Ubuntu 9.04 i stariji, ili Debian 6 x64 (koristit ćemo ga za demonstraciju System V init sustava)
• Ubuntu 14.04 x64 (koristit ćemo ga za demonstraciju Upstarta). Evo vodiča o tome kako jednostavno postaviti svoj Ubuntu poslužitelj.
• CentOS 7 x64 (koristit ćemo ga za demonstraciju Systemda).

Trebali biste imati korisnika sa sudo privilegijama na svakom od poslužitelja koje ćete koristiti za pokretanje naredbi. Ovaj vodič o konfiguriranju Linux sudoers datoteke može vas voditi.

Napomena:  Naredbe u vodiču ometat će rad sistemskih usluga. Stoga ih ne biste trebali primjenjivati na aktivnom produkcijskom poslužitelju.

Razine pokretanja

Razina pokretanja (runlevel) je operativna razina koja opisuje trenutačno stanje Linux sustava u odnosu na to koje su usluge dostupne. Koncept potječe iz System V inita. Kada se Linux sustav pokrene, on inicijalizira kernel, ulazi u jednu razinu pokretanja i pokreće skriptu za pokretanje povezanu s tom razinom pokretanja. Prilikom pokretanja možete izvršiti samo jednu razinu pokretanja.

Ostali primjeri razina pokretanja uključuju stanje isključivanja, način ponovnog pokretanja, jednokorisnički način rada itd. Svaka razina određuje koje će se usluge pokretati u tom stanju. Neke se usluge mogu pokretati na više od jedne razine, dok druge ne mogu.

Postoji sedam razina pokretanja: od 0 do 6. U nastavku je definicija tih sedam razina pokretanja:

• Razina pokretanja 0: Isključivanje sustava
• Razina pokretanja 1: Jednokorisnički i spasilački način rada
• Razine pokretanja 2, 3, 4: Višekorisnički i tekstualni način rada s omogućenim umrežavanjem
• Razina pokretanja 5: Višekorisnički, mrežno omogućen i grafički način rada
• Razina pokretanja 6: Ponovno pokretanje sustava

Razine pokretanja ne moraju se nužno izvršavati slijedno. Razine pokretanja 2, 3 i 4 razlikuju se ovisno o distribuciji Linuxa koju koristite. Razinu pokretanja 4 možete implementirati u nekim distribucijama, a u drugima ne. Kada ste omogućili automatsko pokretanje usluge, kao što je objašnjeno u prvom dijelu, zapravo ste je dodali u razinu pokretanja. U sustavu System V, operacijski sustav počinje s određenom razinom pokretanja, a tijekom pokretanja pokušava pokrenuti sve usluge povezane s tom razinom pokretanja. Razine pokretanja su ciljevi u Systemd-u, o čemu ćemo raspravljati u odjeljku o Systemd-u.

Init i PID 1

Init sustav je prvi proces koji se pokreće kada se Linux sustav podigne i kernel učita u memoriju. Obavlja različite zadatke, uključujući određivanje načina na koji će se korisnički proces ili sistemska usluga učitati, kojim redoslijedom i treba li se automatski pokrenuti. U svakoj distribuciji Linuxa svaki je proces identificiran ID-jem procesa (PID), a init ima PID 1. On je roditelj svih ostalih procesa koji se sukcesivno pokreću kako se sustav podiže.

Povijest sustava init

Sustav init koji se nalazi u novijim Linux distribucijama poboljšanje je u odnosu na izvorni. Najranije verzije Linux distribucija koristile su System V init, koji se na sličan način koristio u Unix sustavima. Kako se Linux razvijao, implementiran je Upstart init demon – stvorio ga je Ubuntu. Sada (u vrijeme pisanja ovog vodiča, 2021.) imamo Systemd init demon – koji je prvi implementirao Fedora. Kako se Linux sustavi nastavljaju razvijati, možda će se pojaviti noviji init sustav. U ovom vodiču raspravljat ćemo o ova tri: System V, Upstart i Systemd.

Novije verzije Linuxa dolaze sa Systemd init sustavom prema zadanim postavkama. Međutim, zadržale su druge starije init sustave radi povratne kompatibilnosti. Postoje različite implementacije System V-a koje možete koristiti u drugim varijantama Linuxa. Na primjer, FreeBSD, varijanta UNIX-a, koristi BSD init. Starije verzije Debiana koriste SysVinit. Obje potječu od System V-a.

Način na koji svaka verzija init demona upravlja uslugama je drugačiji. Poboljšanja dodana u svaku verziju bila su usmjerena prema robusnom alatu za upravljanje uslugama koji bi rješavao sve što Linux sustavu treba od usluga, uređaja, portova i drugih resursa. Postojala je potreba za moćnim sustavom koji bi mogao paralelno učitavati resurse i koji bi se mogao elegantno oporaviti od rušenja sustava.

System V init sekvenca

System V koristi inittab datoteku za pohranu uputa za inicijalizaciju. Upstart zadržava inittab datoteku radi povratne kompatibilnosti. Evo tijeka pokretanja sustava System V:

• Sustav init dolazi iz binarne datoteke /sbin/init.
• Nakon što se sustav init učita u memoriju, čita svoju prvu datoteku na /etc/inittab.
• Jedan od zapisa u ovoj datoteci određuje razinu pokretanja (runlevel) na kojoj bi se računalo trebalo pokrenuti. Na primjer, ako je vrijednost za razinu pokretanja navedena kao 5, Linux će se pokrenuti u višekorisničkom, grafičkom načinu rada s omogućenim umrežavanjem (uobičajeno u distribucijama dizajniranim za stolna računala). Ovdje navedena razina pokretanja poznata je kao zadana razina pokretanja jer će se uvijek koristiti.
• Zatim sustav init traži dalje u /etc/inittab datoteci i čita koje init skripte treba pokrenuti za tu razinu pokretanja.

Pronalaženjem skripti koje treba pokrenuti za određenu razinu pokretanja, sustav init će pronaći koje usluge treba pokrenuti. Ove init skripte su mjesto gdje obično konfigurirate ponašanje pri pokretanju za pojedinačne usluge, na isti način na koji konfiguriramo MySQL uslugu u prvom dijelu ovog vodiča.

Struktura System V init skripti

U ovom odjeljku detaljno ćemo pogledati init skripte. Konfiguracijske datoteke sustava System V ili init skripte su ono što kontrolira usluge. Init skripte inicijaliziraju uslugu, otuda i naziv init skripta.

Svaka usluga ima svoju init skriptu. Na primjer, MySQL init skripta kontrolira MySQL poslužitelj. Dobavljači aplikacija osiguravaju init skripte za svoju specifičnu aplikaciju, dok izvorne Linux usluge dolaze s instalacijom operativnog sustava. Kada izradite prilagođenu aplikaciju, za nju možete izraditi i vlastite prilagođene init skripte.

Za pokretanje usluge poput MySQL poslužitelja, njegov se binarni program najprije učitava u memoriju. Ovisno o njegovoj konfiguraciji, program se može nastaviti izvršavati u pozadini kako bi nastavio prihvaćati veze klijenata. Init skripta usluge upravlja pokretanjem, zaustavljanjem ili ponovnim učitavanjem binarne aplikacije. Init skripte u sustavu System V su shell skripte. Drugi naziv za njih su rc (run command) skripte.

Struktura direktorija sustava System V

Nadređeni direktorij za init skripte je /etc direktorij. Direktorij /etc/init.d stvarni je direktorij za init shell skripte. Skripte su simboličkim poveznicama povezane s rc direktorijima.

Postoji nekoliko rc direktorija unutar /etc direktorija, svaki s brojem u nazivu. Brojevi predstavljaju različite razine pokretanja. Ako izlistate sadržaj direktorija, vidjet ćete nazive poput /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, itd.

Ako pogledate sadržaj svakog od rc direktorija, vidjet ćete datoteke koje počinju s K ili S u svom nazivu datoteke, nakon čega slijede dvije znamenke. Te datoteke sadrže simboličke veze koje pokazuju natrag na stvarne init shell skripte stvarnog programa. Slova K i S su kratice: K znači Kill ili Stop, dok S označava Start. Dvije znamenke u nazivima datoteka predstavljaju redoslijed izvršavanja. Ako vidite datoteku pod nazivom K05script_name, ona će se izvršiti prije datoteke pod nazivom K09script_name.

Pokretanje

Nastavljajući s redoslijedom pokretanja, pogledajmo kako se pozivaju init skripte.

S i K skripte ne poziva izravno init sustav. Umjesto toga, poziva ih druga skripta: /etc/init.d/rc skripta. Datoteka /etc/inittab upućuje init daemon u kojem se runlevelu sustav treba po zadanim postavkama pokrenuti. Ovisno o navedenom runlevelu, redak u /etc/inittab datoteci poziva /etc/init.d/rc skriptu, prosljeđujući zadani runlevel kao parametar. Koristeći ovaj parametar, skripta će pozvati datoteke pod odgovarajućim /etc/rcN.d direktorijem, gdje N označava runlevel. Na primjer, ako se poslužitelj pokrene s runlevelom 5, pozvat će se odgovarajuće datoteke pod /etc/rc5.d direktorijem.

Unutar rc direktorija, sve K skripte se pokreću numerički s argumentom stop, dok se sve S skripte pokreću na sličan način s argumentom start. Odgovarajuće stvarne init shell skripte za program na koje upućuju simboličke veze pod /etc/rcN.d bit će pozvane s parametrima stop i start odnosno.

Jednostavno rečeno, kad god Linux sustav uđe ili prijeđe na određeni runlevel, pokrenut će se određene skripte za zaustavljanje nekih usluga, dok će se druge pokrenuti za pokretanje drugih usluga. Ovaj proces osigurava da se svaki proces koji ne bi trebao raditi u određenom stanju Linuxa zaustavi, a svaki proces koji bi trebao raditi pokrene automatski.

Automatsko pokretanje System V

Kada omogućite automatsko pokretanje usluge pri pokretanju sustava, izravno mijenjate ponašanje init-a. Na primjer, ako konfigurirate uslugu da se automatski pokreće na runlevelu 2, init proces stvara odgovarajuće simboličke veze u /etc/rc2.d direktoriju. Kako bismo vam pomogli razumjeti, objasnit ćemo to na primjeru.

Primjer System V

Kako bismo vam dali praktičan primjer, koristit ćemo konfiguraciju MySQL usluge iz 1. dijela. Stoga se prijavite na Debian 6 VPS sa svojim sudo/root korisnikom koristeći ssh (ili putty ako ste na Windowsima) i nastavite sa sljedećim koracima.

Korak 1: Otvorite i pregledajte inittab datoteku

Najprije unesite sljedeću naredbu za pregled sadržaja inittab datoteke u terminalu:

Sadržaj datoteke trebao bi izgledati otprilike ovako:

Broj 2 označava runlevel s kojim se sustav pokreće. U ovom slučaju, runlevel 2 je zadani, stoga će se ovaj Debian sustav pokrenuti u runlevelu 2 kao višekorisnički, tekstualni način rada. Možete pokrenuti sljedeću naredbu za potvrdu:

Prikazat će izlaz sličan ovome:

Korak 2: Pregledavanje rc direktorija

Zatim, kako biste izlistali rc direktorije, pokrenite sljedeću naredbu:

Evo snimke zaslona izlaza:

Kao što smo ranije vidjeli u inittab datoteci, sustav je konfiguriran za pokretanje u runlevelu 2, stoga će se skripte pod /etc/rc2.d izvršiti pri pokretanju sustava. Sadržaj ovog direktorija možete izlistati pomoću naredbe:

Kao što možete vidjeti iz izlaza, datoteke su samo simboličke veze koje pokazuju na stvarne datoteke skripti pod /etc/init.d. Evo isječka izlaza:

U ovom direktoriju nema K skripti, samo S (start) skripte. Skripte će pokrenuti ovdje povezane usluge, poput rsync. Također možete primijetiti da je navedena usluga mysql o kojoj raspravljamo u sljedećoj podtemi.

Korak 3: Pregledavanje Init skripte

Kada se instalira usluga koja je kompatibilna sa System V, ona stvara shell skriptu u direktoriju /etc/init.d. Dostupnost MySQL shell skripte možete provjeriti unosom sljedeće naredbe:

Prikazuje sljedeći izlaz:

Datoteka je prilično velika. Možete unijeti sljedeću naredbu kako biste vidjeli njezin sadržaj:

Korak 4: Korištenje chkconfig ili sysv-rc-conf

Chkconfig je naredba koju možete koristiti u distribucijama temeljenim na RHEL-u kao što je CentOS za omogućavanje ili onemogućavanje usluga kompatibilnih sa System V. Također je možete koristiti za popis instaliranih usluga i njihovih odgovarajućih razina pokretanja. Evo naredbe za to (radi na CentOS-u):

U Debian distribucijama takav uslužni program ne postoji izvorno. update-rc.d u Debian sustavima samo instalira i uklanja usluge s razina pokretanja. Dostupan je prilagođeni alat koji možete koristiti kako biste donijeli funkcionalnost chkconfig na Debian sustave. Unesite sljedeću naredbu da biste ga instalirali:

Nakon što se instalira, možete pokrenuti sljedeću naredbu kako biste vidjeli ponašanja razina pokretanja za različite usluge:

Izlaz ove naredbe oblikovan je u tablicu koja prikazuje naziv usluge s lijeve strane i razinu pokretanja pod kojom se usluga izvodi:

X označava razinu pokretanja pod kojom će se usluga izvoditi. Ovaj vam alat omogućuje onemogućavanje ili omogućavanje usluge za određenu razinu pokretanja pomoću tipki sa strelicama i razmaknice. Za izlazak iz alata pritisnite Q.

Korak 5: Testiranje ponašanja pokretanja MySQL-a tijekom podizanja sustava

Na gornjoj snimci zaslona možete vidjeti da je usluga mysql omogućena na razinama pokretanja 2,3,4,5. Možete onemogućiti MySQL pomoću sljedeće naredbe:

Izlaz izgleda ovako. Primijetite da je usluga zaustavljena za sve razine pokretanja:

Pokrenite naredbu u nastavku kako biste vidjeli sadržaj direktorija:

Pogledajte redak mysql u izlazu u nastavku:

Izlaz pokazuje da se simbolička poveznica promijenila u K, što znači Kill (zaustavi). Stoga se MySQL prema zadanim postavkama neće automatski pokrenuti na razini pokretanja 2. Kad god omogućite ili onemogućite uslugu u System V, to je ono što se događa. Sve dok postoji S (start) skripta u zadanom direktoriju razine pokretanja za uslugu, init daemon će pokrenuti tu uslugu tijekom podizanja sustava.

Da biste ponovno omogućili uslugu, unesite sljedeću naredbu:

Korak 6: Testiranje ponašanja pokretanja MySQL-a nakon rušenja sustava

U ovom odjeljku raspravljat ćemo o tome kako System V rješava rušenja usluga. Ovo znanje možete koristiti za konfiguriranje ponašanja vaših prilagođenih usluga nakon rušenja.

U prvom dijelu ovog vodiča napravili smo izmjenu u datoteci /etc/inittab kako bismo omogućili automatsko pokretanje MySQL-a nakon rušenja. Dodali smo sljedeći redak kako bismo omogućili ovo ponašanje:

Ovo ponašanje možemo provjeriti s nekoliko testova. Prvo ponovno pokrenite svoj VPS unosom sljedeće naredbe:

Nakon ponovnog pokretanja provjerite s kojim se ID-ovima procesa izvode mysql_safe i mysqld, unesite sljedeću naredbu da biste dobili ID-ove procesa:

Izlaz koji smo dobili bio je:

Zabilježite ID-ove procesa. U našem slučaju to su bili 1836 i 186338. Sada simulirajte rušenje tako da ubijete proces s prekidačem -9 unosom sljedeće naredbe. Ne zaboravite zamijeniti s ID-ovima vaših procesa:

Nakon nekoliko minuta provjerite status MySQL-a pokretanjem sljedeće naredbe:

Izlaz pokazuje da MySQL radi, što znači da je ponovno pokrenut nakon simuliranog rušenja. Ako ponovno pokrenete ps -ef | grep mysql naredbu, vidjet ćete da se i mysqld_safe i mysqld procesi izvode, iako s novim ID-ovima.

Možete pokušati ubiti procese više puta i oni će se ponovno pokrenuti nakon nekoliko minuta. Ovo ponašanje omogućuje redak koji smo dodali u /etc/inittab datoteku. Na ovaj način konfigurirate usluge da se automatski ponovno pokrenu nakon rušenja u sustavu System V. Da biste ponovno vidjeli sintaksu, pogledajte 1. dio ovog vodiča.

Neke prilagođene usluge mogu imati pogreške i ne uspjeti se ponovno pokrenuti nakon više pokušaja. Init demon će pokušati ponovno pokrenuti uslugu, ali ako ne uspije više od deset puta u roku od dvije minute, Linux sustav onemogućuje uslugu na do 5 minuta. To pomaže u održavanju stabilnosti sustava i osigurava da se resursi sustava ne troše na usluge koje se ruše. Dobra je ideja provjeriti zapisnike sustava kako biste identificirali probleme s vašim prilagođenim aplikacijama koje je potrebno popraviti.

Uvod u Upstart

Sustav System V init već je dugo vremena ključan za Linux distribucije. Međutim, kao što je to slučaj s tehnologijom, ona stalno napreduje. Ekosustav Linuxa strahovito je narastao zahvaljujući podršci zajednice otvorenog koda. System V učitava poslove i usluge na serijalizirani način, što donosi složenost i troši vrijeme. Osim toga, uvođenje modernih priključnih medija za pohranu, za koje System V nije bio dizajniran, potaknulo je potrebu za drugačijim init sustavom.

Programeri u Ubuntuu počeli su raditi na drugom sustavu inicijalizacije. Ovaj init sustav dizajniran je za brže učitavanje operativnog sustava, osiguravanje urednog čišćenja srušenih usluga, održavanje predvidljivosti ovisnosti između sistemskih usluga i podršku za priključne medije za pohranu. Rođen je Upstart demon.

Upstart init ima nekoliko prednosti u odnosu na System V init na sljedeće načine:

• Upstart ne učitava usluge serijski kao System V, čime se skraćuje vrijeme pokretanja sustava.
• Dizajniran je za bolje rukovanje srušenim uslugama uz uredno čišćenje i ponovno pokretanje usluga.
• Upstart koristi fleksibilan sustav događaja za prilagodbu rukovanja uslugama u različitim stanjima.
• Ovaj init izbjegava složene shell skripte za učitavanje i upravljanje uslugama kao u System V. Upstart koristi jednostavne konfiguracijske datoteke koje je lako razumjeti i mijenjati.
• Upstart je napravljen imajući na umu kompatibilnost unatrag. Skripta /etc/init.d/rc i dalje se izvodi za upravljanje izvornim System V uslugama.
• Izbjegava držanje suvišnih simboličkih poveznica koje sve upućuju na istu skriptu.

Upstart događaji

Upstart se temelji na događajima, što omogućuje povezivanje više događaja s istom uslugom. Ova arhitektura temeljena na događajima osigurava fleksibilno upravljanje uslugama. Svaki događaj može pozvati shell skriptu specifičnu za taj događaj.

Upstart događaji uključuju:

• Starting
• Started
• Stopping
• Stopped

Između događaja, usluga može biti u različitim stanjima uključujući, ali ne ograničavajući se na:

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

Upstart init može se konfigurirati za poduzimanje radnji za svako od ovih stanja, otuda i njegov fleksibilan dizajn.

Redoslijed pokretanja Upstart Init-a

Upstart init pokreće /etc/init.d/rc skriptu pri pokretanju, baš kao i System V. Ova skripta normalno pokreće sve System V init skripte kako bi se osigurala kompatibilnost unatrag.

Upstart konfiguracijske datoteke nalaze se u /etc/init direktoriju, pa tamo traži prema zadanim postavkama i izvršava shell naredbe pronađene u konfiguracijskim datotekama unutar tog direktorija.

Upstart konfiguracijske datoteke

Upstart init koristi konfiguracijske datoteke usluga za upravljanje uslugama, za razliku od bash skripti koje se koriste u System V. Standard imenovanja za ove konfiguracijske datoteke usluga je service_name.conf.

Datoteke sadrže običan tekstualni sadržaj podijeljen u različite odjeljke koji se nazivaju strofe (stanzas). Svaka strofa opisuje različito stanje usluge i njezino ponašanje. Različite strofe kontroliraju različite događaje usluge. Na primjer, čekanje (waiting), prije pokretanja (pre-start), pokretanje (start), prije zaustavljanja (pre-stop), zaustavljanje (stopping) itd.

Strofa sadrži naredbe ljuske, što omogućuje pokretanje nekoliko radnji za svaki događaj za svaku uslugu. Osim toga, svaka konfiguracijska datoteka usluge specificira sljedeće dvije stvari:

• Na kojim razinama pokretanja (runlevels) bi se usluga trebala pokrenuti i zaustaviti.
• Treba li se usluga ponovno pokrenuti (respawn) ako se sruši.

Struktura direktorija Upstart

Konfiguracijske datoteke Upstart usluga nalaze se pod /etc/init direktorijem. Nemojte ovo pomiješati s /etc/init.d.

Primjer Upstarta

U ovom primjeru vidjet ćemo kako Upstart upravlja uslugom tijekom podizanja sustava i u slučaju rušenja. Detaljnije ćemo objasniti praktične primjere prikazane u prvom dijelu ovog vodiča.

Korak 1: Prijavite se na poslužitelj Ubuntu 14.0.4

Prvo, za testiranje Upstarta, koristit ćemo drugi VPS, onaj koji vrti Ubuntu 14.0.4. To je zato što ova Linux distribucija izvorno implementira Upstart. Koristite ssh ili putty ako ste na Windowsima. Morate se prijaviti s korisnikom koji ima root ili sudo privilegije. Imam korisnika koji se zove hackins, pa bih se ovako prijavio:

Zamijenite sa svojim root/sudo korisnikom i javnom IP adresom poslužitelja. Zatim pritisnite enter i unesite lozinku ili pristupnu frazu.

Korak 2: Ispitajte direktorije init i rc

Konfiguracijske datoteke Upstarta pohranjene su u direktoriju /etc/init. To je direktorij koji ćete koristiti pri izradi novih konfiguracijskih datoteka usluga.

Za popis naziva konfiguracijskih datoteka u direktoriju /etc/init, izvršite sljedeću naredbu:

Kao što ćete vidjeti iz izlaza gornje naredbe, mnoge usluge rade pod Upstartom. Pritisnite Q za izlaz iz less.

Ako pokrenete sljedeće za popis konfiguracijskih datoteka usluga za System V u rc direktoriju, vidjet ćete samo nekoliko:

Korak 3: Ispitajte Upstart datoteku

U prvom dijelu ovog vodiča koristili smo mysql.conf datoteku kako bismo naučili o konfiguraciji poslužitelja. Kako bismo proširili svoje znanje, upotrijebimo drugu konfiguraciju. Konfiguracijska datoteka cron dobar je kandidat. Unesite sljedeću naredbu za otvaranje datoteke:

Trebali biste dobiti izlaz sličan snimci zaslona u nastavku:

Skripta je prilično jednostavna. Obratite pozornost na sljedeća važna polja: start on, stop on, fork, i respawn. Definirajmo što ove direktive rade:

• start on nalaže Ubuntuu da pokrene cron daemon kada sustav uđe u razine pokretanja (runlevels) 2, 3, 4 ili 5. Neće se pokrenuti na drugim razinama pokretanja koje ovdje nisu navedene, tj. 0, 1 ili 6.
• stop on nalaže Ubuntuu da zaustavi pokrenuti daemon. Međutim, u ovom slučaju postoji uskličnik (!) koji je znak negacije. Skripta se ne bi trebala zaustaviti na razinama pokretanja nakon uskličnika: 2,3,4,5.
• fork direktiva nalaže Upstartu da odvoji proces od konzole i ostavi ga da radi u pozadini.
• respawn direktiva nalaže sustavu da automatski pokrene cron ako se sruši iz bilo kojeg razloga.

Pritisnite Ctrl X za izlaz iz uređivača bez upisivanja ičega.

Ostale Upstart konfiguracijske datoteke slijede istu strukturu, sa strofama za start, stop i respawn. Neke konfiguracijske datoteke mogu imati dodatne blokove skripti za pre-start, pre-stop, post-start i više. Ovi blokovi koda govore sustavu što treba izvršiti kada je proces u bilo kojem od definiranih stanja.

Korak 4: Testirajte ponašanje pokretanja MySQL usluge nakon podizanja sustava

MySQL je prema zadanim postavkama postavljen na automatsko pokretanje nakon podizanja sustava. Pokušat ćemo ga onemogućiti i vidjeti ponašanje. U Upstartu, usluga se može onemogućiti stvaranjem datoteke pod nazivom service_name.override pod /etc/init/ direktorijem. Sadržaj datoteke je samo jedna riječ: manual.

Pogledajmo kako možemo koristiti ovu naredbu za onemogućavanje MySQL usluge. Unesite sljedeću naredbu za otvaranje datoteke u uređivaču nano:

U otvorenoj datoteci dodajte sljedeći redak:

Spremite promjene pritiskom na Ctrl + O, a zatim Enter. Izađite iz uređivača pritiskom na Ctrl + X. Pokrenite sljedeću naredbu za ponovno pokretanje poslužitelja:

Pričekajte nekoliko minuta, a zatim se ponovno prijavite. Nakon što se ponovno prijavite, testirajte status MySQL usluge unosom sljedeće naredbe:

Izlaz će pokazati da usluga nije pokrenuta:

To znači da se MySQL nije automatski pokrenuo nakon podizanja sustava. Zatim otvorite konfiguracijsku datoteku MySQL-a i provjerite je li se direktiva start promijenila:

Izlaz će pokazati da se ništa nije promijenilo:

To znači da ako se vaša usluga ne pokreće automatski, a provjeravate samo konfiguracijsku datoteku usluge (service_name.conf), možda nećete pronaći pogrešku. Također biste trebali provjeriti postoji li datoteka service_name.override u direktoriju.

Unesite sljedeću naredbu za brisanje override datoteke i ponovno omogućavanje MySQL usluge. Zatim ponovno pokrenite poslužitelj:

Nakon što se poslužitelj podigne, ponovno testirajte status MySQL usluge:

Trebalo bi se prikazati da se MySQL usluga automatski pokrenula.

Korak 5: Testiranje ponašanja pokretanja MySQL usluge nakon rušenja sustava

Prema zadanim postavkama, MySQL usluga se automatski ponovno pokreće ako se sruši. Da bismo zaustavili ovo ponašanje, uredit ćemo datoteku mysql.conf. Unesite sljedeću naredbu za otvaranje datoteke u uređivaču nano:

Pronađite retke s direktivom respawn i komentirajte ih kao što je prikazano u nastavku s #:

Izvršite sljedeće naredbe za ponovno pokretanje usluge:

Gornje naredbe koristili smo za zaustavljanje i pokretanje usluge jer korištenje initctl restart ili initctl reload ovdje ne bi radilo. Kada pokrenete naredbu za pokretanje MySQL usluge, izlaz će prikazati PID za MySQL poput:

Naš PID bio je 1439. Zatim zabilježite što ste dobili kada ste pokrenuli naredbu, koristit ćemo to u sljedećem koraku. Da biste simulirali rušenje, prekinite MySQL proces pomoću sljedeće naredbe, ne zaboravite zamijeniti svoj PID kako je gore objašnjeno:

Da biste provjerili je li se MySQL ponovno pokrenuo nakon rušenja, pričekajte nekoliko minuta, a zatim unesite sljedeću naredbu:

Izlaz će pokazati da je MySQL zaustavljen:

Pokušajte provjeriti status još nekoliko puta da vidite ima li promjena. Primijetit ćete da MySQL ostaje zaustavljen. To je zato što konfiguracijska datoteka usluge nema direktive respawn (one koje smo komentirali). Pogledajte 1. dio ovog vodiča za više objašnjenja o direktivi respawn.

Zašto smo vam pokazali kako onemogućiti automatsko ponovno pokretanje usluga nakon pokretanja ili rušenja sustava? To je uglavnom u svrhu rješavanja problema. Ako se, na primjer, vaša usluga pokrene i nastavi se rušiti, možda ćete je htjeti onemogućiti kako biste mogli riješiti problem, a ujedno i održati sustav stabilnim. Također možete spriječiti automatsko ponovno pokretanje nekih starih konfiguracija usluga ako slučajno nadogradite na novu Linux distribuciju koja izvorno dolazi s systemd o kojem se raspravlja u sljedećem odjeljku.

Uvod u Systemd

Systemd je najnoviji init sustav koji se nalazi u najnovijim Linux distribucijama. Sadrži mnoge komponente koje čine moderan Linux sustav.

Systemd upravlja ne samo uslugama nego i cijelim Linux sustavom. U ovom odjeljku usredotočit ćemo se na to kako systemd kontrolira ponašanje usluga nakon pokretanja ili rušenja sustava.

Systemd je unatrag kompatibilan sa System V init skriptama i naredbama. Stoga, ako imate bilo koje usluge konfigurirane za System V, one će se također izvoditi pod Systemd-om. Većina administrativnih naredbi za Upstart i System V izmijenjena je kako bi radila sa Systemd-om. Systemd se preimenuje u init prilikom pokretanja sustava. Datoteka /sbin/init postoji i stvara simboličku poveznicu na /bin/systemd.

Konfiguracijske datoteke za Systemd: Jedinične datoteke

Konfiguracija Systemd-a sastoji se od jediničnih datoteka. Svaka jedinična datoteka predstavlja resurs sustava. Dok su druga dva init sustava (tj. System V i Upstart) bila odgovorna za upravljanje uslugama Linux sustava, Systemd ne samo da upravlja demonima usluga, već i drugim vrstama resursa sustava kao što su staze operacijskog sustava uređaja, utičnice, točke montiranja itd. Jedinične datoteke pohranjuju informacije o resursu.

Svaka jedinična datoteka predstavlja određeni resurs sustava s načinom imenovanja service_name.unit_type. To znači da ćete pronaći datoteke poput home.mount, dbus.service, sshd.socket itd. Jedinične datoteke su jednostavne tekstualne datoteke s deklarativnom sintaksom koju je lako razumjeti i mijenjati.

Struktura direktorija

Glavna lokacija izvornih jediničnih datoteka je direktorij /lib/systemd/system/. Jedinične datoteke koje sami izradite ili one koje su prilagođeno izradili administratori sustava, kao i druge izmijenjene izvorne jedinične datoteke, pohranjuju se u direktoriju /etc/systemd/system direktoriju.

Ako jedinična datoteka s istim nazivom postoji i u /lib/systemd/system/ i u /etc/systemd/system direktorijima, systemd će koristiti onu u direktoriju /etc direktoriju.

Kada omogućite pokretanje usluge pri pokretanju sustava ili bilo kojoj drugoj ciljnoj razini/razini pokretanja, stvara se simbolička poveznica za tu jediničnu datoteku usluge u odgovarajućim direktorijima u /etc/systemd/system. Jedinične datoteke u direktoriju /etc/systemd/system samo su simboličke poveznice na datoteke sa sličnim nazivom u direktoriju /lib/systemd/system direktoriju.

Redoslijed pokretanja Systemd-a: Ciljne jedinice

Ciljne jedinice jedinstvene su vrste jediničnih datoteka koje obično imaju sufiks .target. Ciljne jedinice razlikuju se od ostalih vrsta jediničnih datoteka jer ne predstavljaju jedan određeni resurs. Umjesto toga, one predstavljaju stanje cijelog sustava u određenom trenutku.

Kako bi to postigle, ciljne jedinice grupiraju i pokreću više jediničnih datoteka koje su dio određenog stanja. Iako se Systemd ciljevi i System V razine pokretanja mogu labavo usporediti, oni nisu isti. Ciljna jedinična datoteka ima naziv umjesto broja. Na primjer, naći ćete nešto poput multi-user.target umjesto runlevel 3 ili reboot.target umjesto runlevel 6. Linux sustav se može pokrenuti s multi-user.target. U ovom slučaju, to u osnovi dovodi poslužitelj na razinu pokretanja 2, 3 ili 4, što pokreće sustav u višekorisničkom tekstualnom načinu rada s omogućenim umrežavanjem.

Razlika je u tome kako dovodi poslužitelj na tu razinu. System V pokreće usluge sekvencijalno. S druge strane, kako se sustav pokreće, systemd provjerava postoje li druge usluge ili resursi i određuje njihov redoslijed učitavanja.

Još jedna razlika između systemd ciljnih jedinica i System V razina pokretanja jest ta da će Linux distribucija koja koristi System V postojati u samo jednoj razini pokretanja. Ako izmijenite razinu pokretanja, ona će se jednostavno prebaciti na tu novu razinu pokretanja i postojati u njoj. S druge strane, datoteke ciljnih jedinica mogu biti inkluzivne. Nadalje, aktiviranje ciljne jedinice osigurava da se druge ciljne jedinice učitaju kao njezin dio. Na primjer, ako pokrenete Linux sustav s grafičkim korisničkim sučeljem, on će imati aktiviran graphical.target aktiviran. To pak automatski osigurava da se multi-user.target također učita i aktivira.

Evo tablice koja uspoređuje razine pokretanja i ciljeve.

Razina pokretanja (System V)	Ciljne jedinice (systemd)
razina pokretanja 0	poweroff.target
razina pokretanja 1	rescue.target
razina pokretanja 2,3,4	multi-user.target
razina pokretanja 5	graphical.target
razina pokretanja 6	reboot.target

Systemd default.target

U sustavu systemd, default.target je ekvivalent zadane razine pokretanja u System V. Vidjeli smo da je zadana razina pokretanja u System V bila definirana u datoteci inittab. U sustavu systemd imamo default.target datoteku. Zadana ciljna datoteka pohranjena je u /etc/systemd/system direktoriju. Ona stvara simboličku poveznicu na jednu od datoteka ciljnih jedinica pod /lib/systemd/system. Promjena zadanog cilja jednostavno znači ponovno stvaranje simboličke poveznice i izmjenu razine pokretanja sustava.

U sustavu System V, inittab je specificirao u kojem će direktoriju Linux pronaći init skripte. To je mogao biti bilo koji od rc direktorija, kao što je ranije objašnjeno. S druge strane, zadani cilj sustava systemd određuje jedinice resursa koje se učitavaju prilikom pokretanja. Sve definirane jedinice se učitavaju. Međutim, ne učitavaju se sve paralelno, niti se sve učitavaju sekvencijalno. Učitavanje jedinice resursa ovisi o drugim resursima koje ona želi ili zahtijeva.

Systemd ovisnosti: Wants i Requires

U ovom odjeljku raspravljat ćemo o tome kako Systemd upravlja ovisnostima. Vidjeli smo da je s Upstartom moguće paralelno učitavanje usluga kada se koriste konfiguracijske datoteke. Također smo raspravljali o tome kako System V koristi razine pokretanja kako bi odredio koju uslugu automatski pokrenuti ili pričekati dok se druga usluga ili resurs ne pojavi. Slično tome, Systemd usluge mogu se konfigurirati da se učitavaju u jednom ili više ciljeva, ili da čekaju dok se druga usluga ili resurs ne pojavi.

U sustavu Systemd, datoteka jedinice koja zahtijeva drugu jedinicu neće se pokrenuti dok se zahtijevana jedinica ne učita i postane aktivna. Ako se zahtijevana jedinica ne uspije učitati dok je prva jedinica aktivna, prva jedinica će se zaustaviti.

Ovo ponašanje osigurava stabilnost sustava. Usluga koja zahtijeva određeni resurs (na primjer, port) kako bi bila dostupna i aktivna može se na taj način natjerati da čeka dok resurs ne postane dostupan (tj. dok se port ne otvori).

Nasuprot tome, jedinica koja želi drugu jedinicu ne nameće takva ograničenja. Neće se zaustaviti ako se željena jedinica zaustavi dok je pozivajuća jedinica još uvijek aktivna. Na primjer, neke nebitne usluge u načinu rada graphical-target.

Systemd primjer

Pogledajmo kako možemo konfigurirati ponašanje usluge pod sustavom systemd.

Korak 1: Prijavite se na svoju VPS instancu

Koristit ćemo MySQL kao uslugu iz stvarnog života i CentOS 7 kao poslužitelj. Kako biste praktički prošli kroz korake i razumjeli koncepte, prijavite se na svoj CentOS 7 VPS ili izradite ga na CloudSigma. VPS koji pokreće distribuciju CentOS 7, Debian 7 ili 8, ili Ubuntu 15 ili noviju prikladan je za ovaj odjeljak jer svi dolaze sa sustavom systemd. Prijavite se pomoću naredbe ssh ili ako ste na Windowsima, koristite PuTTY:

Korak 2: Ispitajte datoteku default.target i ovisnosti

Redoslijed pokretanja sustava Systemd slijedi dugi lanac ovisnosti o kojima ćemo detaljno raspravljati u ovom odjeljku.

• default.target

Datoteka default.target kontrolira usluge koje se pokreću tijekom normalnog podizanja sustava. Možete izlistati zadanu datoteku ciljne jedinice pomoću sljedeće naredbe:

Izlaz prikazuje nešto poput snimke zaslona u nastavku:

Snimka zaslona pokazuje da zadani cilj stvara simboličku poveznicu na datoteku multi-user.target u /lib/systemd/system/ direktorij. To znači da će se sustav prema zadanim postavkama pokrenuti pod multi-user.target, što je ekvivalentno runlevel 3.

• multi-user.target.wants

Da biste vidjeli sve usluge koje datoteka multi-user.target zahtijeva, unesite sljedeću naredbu:

Izlaz sadrži mnogo redaka, evo isječka:

Kao što izlaz pokazuje, to su simboličke veze koje pokazuju na stvarne datoteke jedinica u /lib/systemd/system/ direktoriju. Istaknuli smo mysqld.service kako bismo vam ukazali na to da je također dio multi-user.target. Ako želite potvrditi je li određena usluga konfigurirana za pokretanje, možete izmijeniti naredbu za tu datoteku. Na primjer, možemo filtrirati izlaze kako bismo pronašli mysql ili cron daemon pomoću sljedećih naredbi:

Izlaz će prikazati:

Za filtriranje rezultata za cron daemon, unesite sljedeću naredbu:

Izlaz će prikazati:

Osim multi-user.target, postoje i druge vrste ciljeva, npr. system-update.target ili basic.target.

Unesite sljedeću naredbu da biste vidjeli o kojim ciljevima ovisi multi-user target:

Izlaz prikazuje:

To znači da se basic-target mora prvo učitati kako bi se sustav pokrenuo u multi-user.target načinu rada.

• basic-target

Unesite sljedeću naredbu da biste vidjeli koje druge ciljeve basic.target zahtijeva:

Izlaz će prikazati:

• sysinit.target

Možete pokrenuti sljedeću naredbu kako biste vidjeli postoje li zahtijevani ciljevi za sysinit.target. Sintaksa naredbe je ista. Možete je nastaviti mijenjati kako biste vidjeli koje su ciljne jedinice potrebne drugoj ciljnoj jedinici. Evo naredbe:

Izlaz će pokazati da nema zahtijevanih jedinica za sysinit.target. Možemo provjeriti postoje li druge usluge i ciljevi potrebni za sysinit.target pomoću sljedeće naredbe:

Izlaz prikazuje dugačak popis usluga i ciljeva koje želi sysinit.target. Dio izlaza možete vidjeti u nastavku:

Tijekom inicijalizacije sustava sa system4, sustav ne ostaje samo u jednom cilju. Umjesto toga, učitava usluge na ovisan način dok prelazi s jednog cilja na drugi.

Korak 3: Ispitivanje datoteke jedinice

Pogledajmo kako izgleda datoteka jedinice. Koristili smo datoteku jedinice MySQL usluge u prvom dijelu ovog vodiča, i ponovno ćemo je koristiti. Međutim, možemo pogledati i drugu datoteku jedinice usluge – datoteku jedinice sshd. Unesite sljedeću naredbu za otvaranje konfiguracijske datoteke sshd:

Ispod je snimka zaslona koja prikazuje retke u datoteci:

Kao što vidite, označeni blokovi koda u datoteci olakšavaju razumijevanje i izmjenu kad god je to potrebno. U nastavku su navedene neke važne direktive koje treba razumjeti:

• After – After klauzula govori sustavu da učita uslugu tek nakon što se učitaju navedeni ciljevi i usluge. U ovom slučaju, SSHD usluga će se učitati nakon što se učitaju mrežni cilj i keygen usluga.
• Wants – Wants klauzula pokazuje koji ciljevi žele ovu uslugu. U ovom slučaju ssh-keygen.service želi sshd.service. Međutim, ako sshd ne uspije ili se sruši, to neće isključiti ssh-keygen.service.

Pritisnite Ctrl + X za zatvaranje uređivača.

Korak 4: Testiranje ponašanja pokretanja MySQL usluge pri podizanju sustava

U ovom odjeljku pokazat ćemo vam kako možete promijeniti i testirati ponašanje MySQL usluge pri podizanju sustava. U prethodnom odjeljku vidjeli smo da mysqld.service je potreban za multi-user.target. Stoga će se automatski pokrenuti pri podizanju sustava.

Uslugu možete onemogućiti pokretanjem sljedeće naredbe:

Pokretanje naredbe pokazuje da je simbolička poveznica za mysql uklonjena iz /etc/systemd/system/multi-user.target.wants/ direktorija. Kako biste to testirali, pokrenite sljedeću naredbu da biste provjerili je li MySQL i dalje potreban za multi-user.target:

Naredba ne vraća ništa. Ako pokušate ponovno pokrenuti poslužitelj i provjeriti status MySQL-a, on neće raditi, što znači da se nije automatski pokrenuo prilikom podizanja sustava.

Sada ponovno omogućite uslugu pomoću naredbe:

Izlaz će prikazati simboličku poveznicu. Ako ponovno pokrenete poslužitelj, MySQL bi se trebao automatski pokrenuti. Omogućavanje Systemd usluge stvara simboličku poveznicu u wants direktoriju zadanog cilja. Onemogućavanje Systemd usluge uklanja simboličku poveznicu iz wants direktorija.

Korak 5: Testiranje ponašanja pokretanja MySQL usluge nakon rušenja usluge

Prema zadanim postavkama, MySQL usluga će se automatski pokrenuti u slučaju rušenja. Možemo onemogućiti ovo ponašanje u Systemd konfiguracijskoj datoteci za MySQL. Prvo, pogledajmo datoteku. Unesite sljedeću naredbu za otvaranje datoteke:

Snimka zaslona u nastavku prikazuje izlaz:

Vrijednost direktive Restart postavljena je na on-failure. To znači da će se MySQL usluga ponovno pokrenuti nakon nečistih izlaznih kodova, isteka vremena ili nečistih signala. Ispod je tablica koja prikazuje neke od parametara ponovnog pokretanja iz man stranice.

Postavke ponovnog pokretanja/Uzroci izlaza	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
čisti izlazni kod ili signal		X	X
Nečisti izlazni kod		X		X
Nečisti signal		X		X	X	X
Istek vremena		X		X	X
Watchdog		X		X	X		X

Dvije važne direktive u Systemd unit datoteci su Restart i RestartSec. One kontroliraju ponašanje usluge u slučaju rušenja. Restart određuje kada bi se usluga trebala ponovno pokrenuti, a RestartSec određuje koliko dugo treba čekati prije ponovnog pokretanja nakon rušenja. Da biste onemogućili ponašanje ponovnog pokretanja, komentirajte direktivu Restart dodavanjem # na početak retka kao što je prikazano:

Sada ponovno učitajte sistemski daemon, a zatim ponovno učitajte mysqld uslugu pomoću sljedećih naredbi:

Zatim pokrenite sljedeću naredbu kako biste pronašli glavni PID (Main PID) MySQL usluge:

Glavni PID za naš test bio je 23809. Zabilježite svoj kako biste ga koristili u sljedećoj naredbi. Pomoću naredbe kill -9 simulirajte rušenje prekidanjem procesa. Također, ne zaboravite zamijeniti s brojem procesa koji ste dobili u svom testu:

Ako pokrenete naredbu koja provjerava status MySQL-a, vidjet ćete da nije aktivan i da se nije uspio ponovno pokrenuti:

Ostat će u stanju kvara (failed) sve dok je direktiva Restart komentirana u mysqld.service konfiguracijskoj datoteci. Ovo emulira rušenje u kojem se usluga zaustavlja i ne pokreće se ponovno.

Da biste ponovno omogućili uslugu, možete urediti mysqld.service konfiguracijsku datoteku, odkomentirati direktivu Restart, a zatim spremiti i zatvoriti. Kao što ste učinili ranije, ponovno učitajte daemon i ponovno pokrenite uslugu. To vraća uslugu na njezinu početnu konfiguraciju i sada se može automatski pokrenuti nakon rušenja. Na kraju, to je sve za konfiguriranje usluge za automatsko pokretanje nakon rušenja. Ako želite konfigurirati usluge za automatsko pokretanje nakon rušenja, jednostavno trebate dodati direktivu Restart, (a ako želite, možete dodati i direktivu RestartSec), pod odjeljkom [Service] datoteke jedinice usluge.

Zaključak

U ovom smo vodiču raspravljali o tome kako Linux upravlja uslugama tijekom pokretanja ili nakon rušenja. Kako bismo razumjeli proces inicijalizacije Linux sustava, raspravljali smo o tri init sustava koje Linux koristi: System V, Upstart i Systemd. Raspravljali smo o njihovoj evoluciji i o tome kako svaki init proces radi u odnosu na automatsko pokretanje usluge nakon ponovnog pokretanja sustava ili rušenja.

Budući da su se i init demoni i Linux distribucije razvijali tijekom vremena, ne zaboravite provjeriti verziju Linux distribucije koju koristite kako biste znali koji init demon vaš sustav nativno podržava.

Nativne Linux aplikacije i većina aplikacija trećih strana već se automatski pokreću nakon podizanja ili rušenja sustava, tako da nećete morati ništa poduzimati. Znanje iz ovog vodiča ključno je kada konfigurirate ponašanje pokretanja i ponovnog pokretanja vlastitih prilagođenih servisa ili kada rješavate probleme sa servisima koji se neprestano ruše.

Ugodan rad na računalu!