Gilios „Ubuntu Linux“ sistemos įžvalgos - ar tai matome?

LINUX , kaip žinome, yra branduolys, o ne operacinė sistema, tiekiama su keliais paskirstymais, tokiais kaip: Debian, Fedora, Ubuntu ir kt. ir daug daugiau. Marko Shuttlewortho sukurta „Ubuntu“ OS yra daugeliui žinoma ir plačiai naudojama. Be to, būdama nemokama ir atviro kodo, kasmet išleidžiama jos naujoji versija, prie kurios prisideda tūkstančiai kūrėjų, prisidedančių prie jos kūrimo. Bet kaip tai veikia? Kokie visi procesai, įvykių sąrašas priverčia jį veikti ir kokia yra šių procesų reikšmė?

Šis straipsnis jus šiek tiek gilintų į labai įdomius Ubuntu OS vidinius elementus, kurie padėtų naujokui visiškai suprasti jo veikimą.

Sistemos išdėstymas

„Linux“ turi savo veikimo procesą, kiekviena sistemos paslauga, įskaitant energijos valdymą, paleidimą, sistemos gedimų valdymą, yra procesas, kurio konfigūracijos failas yra „/etc/init “, apibūdinantis įvykį, kuriame jis vykdys ir atitinkamą įvykį, kuriame sustabdys jo vykdymą, taip pat prižiūri kitus konfigūracijos failus, kurie aprašo jos vykdymo laiką sistemos kataloge „/etc/“, taip sukurdami sistemą įvykio varomas vienas.

Jei yra sugeneruotų įvykių, kažkas turėtų būti ten, kad juos sugautų ir įvykdytų? Akivaizdu, kad valdiklis yra pagrindinis mūsų procesas, kuris egzistuoja kaip visų procesų, turinčių proceso ID 1 , t. Y. init , pirminis procesas. Tai procesas, kuris prasideda nuo sistemos paleidimo ir niekada nesustoja. Šis procesas miršta tik tada, kai sistema yra išjungta, nes nėra proceso, kuris būtų „init“ tėvas.

Ankstesnėse Ubuntu versijose prieš 6.10 buvo senojo stiliaus sysvinit , kuris buvo naudojamas scenarijams paleisti „ /etc/rcx.d “katalogą kiekviename sistemos paleidime ir išjungime. Bet po to paleidimo sistema pakeitė senojo stiliaus sysvinit sistemą, tačiau vis tiek užtikrina jos atgalinį suderinamumą.

Naujausiose „Ubuntu“ versijose yra ši naujovinama sistema, tačiau nuo jos evoliucijos nuo „Ubuntu 6.10“ ji kelis kartus peržiūrėjo dabartinę versiją 1.13.2 kaip ir 2014 m. Rugsėjo 4 d. turi 2 init procesus, vienas skirtas sistemos procesams ir kitas, kuris valdo dabartinį prisijungusį vartotojo seansą ir egzistuoja tik tol, kol vartotojas bus prisijungęs, dar vadinamas x-session init .

Visa sistema buvo nustatyta kaip hierarchinė sistema, susidedanti iš protėvių ir vaiko santykių, galiojančių iki sistemos išjungimo.

Pvz. : nedidelis hierarchinis ryšys tarp abiejų pradinių procesų yra: sistemos init (1) -> rodymo tvarkyklė (branduolio erdvė) -> rodymo tvarkyklė (vartotojo erdvė) -> vartotojo inicijavimas (arba x- session init).

Sistemos init valdomų procesų konfigūracijos failai yra „/etc/init “, o seanso init valdomi failai yra „/usr/share/upstart “ (kaip pagal dabartines naujovinamas versijas, viršijančias 1.12 ), ir šie konfigūracijos failai yra raktas į daugybę atkastų procesų paslapčių, aprašytų šiame straipsnyje.

Dar giliau patekti į hierarchiją

„Ubuntu“ atpažįsta dviejų tipų procesus:

1. Trumpalaikiai darbai (arba „darbas ir mirti“ darbai).
2. Ilgaamžiai darbai (arba buvimo ir darbo darbai).

Sistemoje sukurta hierarchija yra susijusi su priklausomybe tarp procesų, kuriuos galime suprasti peržiūrėdami jų konfigūracijos failus. Pirmiausia pradėkime nuo paprasto hierarchinio ryšio tarp procesų, kurie priverčia sistemą paleisti ir suprasti kiekvieno iš jų reikšmę.

Init yra pirmasis procesas, pradedamas įjungiant sistemą ir priskiriamas darbo ir likimo darbui, nes jis niekada nėra nužudomas ir įjungiamas tik laikas, kai nužudoma inicijavimas išjungimas, ty „init“ miršta, ir tai taip pat kartą per sesiją ir tai yra įjungimas. Įjungus „init“ generuoja patį pirmąjį sistemos įvykį, ty paleidimo įvykį. Kiekviename konfigūracijos faile, esančiame „/etc/init “, yra dvi eilutės, apibrėžiančios įvykį, dėl kurio procesas prasideda ir sustoja. Šios eilutės paryškintos toliau pateiktame paveikslėlyje:

Tai yra proceso „failsafe-x konfigūracijos failas, kuris prasideda ir baigiasi sąlygomis apibūdina įvykį, kuriame prasidės procesas. Generuojant paleidimo įvykį pagal init procesą, procesai, kurių paleidimas yra paleidimo sąlyga, yra vykdomi lygiagrečiai ir tai apibrėžia tik hierarchiją, o visi paleidimo metu vykdomi procesai yra init vaikai.

Procesai, kurie prasideda paleidimo metu, yra išvardyti kaip ir visi šie darbai yra „darbas ir mirtis“:

1 . pagrindinio kompiuterio vardas - tai procesas, kuris sistemai tiesiog nurodo pagrindinio kompiuterio pavadinimą, apibrėžtą faile/etc/hostname.

2 . kmod - įkelia branduolio modulius, t. y. visus tvarkykles iš/etc/modules failo.

3 . mountall - Šis procesas sukuria daug įvykių ir yra daugiausia atsakingas už visų įkrovos failų sistemų, įskaitant vietines failų sistemas ir nuotolines failų sistemas, sujungimą.

/proc failas taip pat yra prijungtas būtent šiame procese, o po visų montavimo darbų paskutinis jo sugeneruotas įvykis yra failų sistemos įvykis, kuris toliau verčia hierarchiją tęsti.

4 . plymouth - šis procesas vykdomas paleidus „mountall“ ir yra atsakingas už to, kad būtų rodomas tas juodas ekranas, kuris matomas paleidus sistemą, rodantis kažką panašaus į žemiau pateiktą:

5 . paruoštas plymouth - nurodo, kad plymouth yra aukštyn.

Toliau pateikiamas pagrindinis procesas, kiti procesai, kurie taip pat vykdomi paleidimo metu, yra, pvz., udev-fallback-graphics ir kt. Grįžtant prie įkrovos hierarchijos, trumpai tariant, sekantys įvykiai ir procesai yra tokie patys kaip nuosekliai:

1 . init kartu su paleidimo įvykio generavimu.

2 . mountall montuojamos failų sistemos, plymouth (kartu su pradiniu mountall), rodančiu užrakto ekraną, ir kmod įkeliant branduolio modulius.

3 . vietinės failų sistemos įvykis, kurį sugeneravo „mountall“, todėl dbus paleistas. („Dbus“ yra visos sistemos pranešimų magistralė, sukurianti lizdą, leidžiantį kitiems procesams bendrauti tarpusavyje siunčiant pranešimus į šį lizdą, o imtuvas klausosi pranešimų šiame lizde ir filtruoja jam skirtus pranešimus).

4 . vietinis failų sistema kartu su pradėtu „dbus“ ir „statinis tinklas-up“ įvykiu, kurį sukelia proceso tinklas, kuris taip pat veikia vietiniame failų sistemos įvykyje, tinklo valdytojas veikia.

5 . virtualall-filesystem įvykis, kurį sugeneravo mountall, paleidžia udev. (udev yra „Linux“ įrenginių tvarkyklė, valdanti karštųjų įrenginių prijungimą ir atsakinga už failų kūrimą „/ dev“ kataloge ir jų valdymą.) „udev“ sukuria failus „ram“, „rom“ ir kt. „/ dev“ kataloguose, kuriuos „mountall“ baigė montuoti virtualiai -filesystems ir sukūrė įvykio virtualią failų sistemą, reiškiančią/dev katalogo montavimą.

6 . udev paleidžia „upstart-udev-bridge“, kuris reiškia, kad vietinis tinklas veikia. Tada, kai „mountall“ baigs montuoti paskutinę failų sistemą ir sugeneruos failų sistemos įvykį.

7 . failų sistemos įvykis kartu su statiniu tinklo prijungimo įvykiu sukelia „rc-sysinit“ užduoties vykdymą. Čia ateina atgalinis senesnių „sysvinit“ ir „upstart“ suderinamumas…

9 . rc-sysinit vykdo komandą „telinit“, kuri nurodo sistemos vykdymo lygį.

10 . Gavęs vykdymo lygį, init įvykdo scenarijus, prasidedančius raide „S“ arba „K“ (pradeda darbus, kurių vardo pradžioje yra „S“, ir nužudo tuos, kurių vardo pradžioje yra „K“)/etc/rcX.d (kur „X“ yra dabartinis vykdymo lygis).

Šis nedidelis įvykių rinkinys sukelia sistemos paleidimą kiekvieną kartą, kai ją įjungiate. Šis įvykių sukėlimas yra vienintelis dalykas, atsakingas už hierarchijos sukūrimą.

Dabar įvykio priežastis yra dar vienas aukščiau pateiktas priedas. Kuris procesas sukelia, kuris įvykis taip pat nurodytas tame pačiame proceso konfigūracijos faile, kaip parodyta žemiau šiose eilutėse:

Aukščiau yra proceso mountall konfigūracijos failo skyrius. Tai rodo įvykius, kuriuos skleidžia. Įvykio pavadinimas yra vienas iš žodžio „ įvykis “. Įvykis gali būti apibrėžtas konfigūracijos faile, kaip nurodyta aukščiau, arba gali būti proceso pavadinimas kartu su priešdėliu „pradžia“, „pradžia“, „sustojimas“ arba „sustabdytas“.

Taigi, čia mes apibrėžiame du terminus:

1. Įvykių generatorius : tas, kurio konfigūracijos faile yra eilutė „skleidžia xxx“, kur xxx yra jos valdomo ar generuojamo įvykio pavadinimas.
2. Įvykių gaudytojas : tas, kurio pradžios arba pabaigos sąlyga yra xxx, arba kuris prasideda arba sustoja įvykyje, sukūrė vieną iš įvykių generatorių.

Taigi seka hierarchija, taigi ir priklausomybė tarp procesų:

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

Iki šiol jūs turite suprasti, kaip tėvų ir vaikų priklausomybės tarp procesų hierarchija nustatoma įvykių paleidimo mechanizmu per paprastą įkrovos mechanizmą.

Dabar ši hierarchija niekada nėra santykis „vienas su vienu“, turintis tik vieną tėvą vienam vaikui. Šioje hierarchijoje mes galime turėti vieną ar daugiau tėvų vienam vaikui arba vieną procesą, kai esame daugiau nei vieno vaiko tėvai. Kaip tai pasiekiama? Na, atsakymas slypi pačiuose konfigūracijos failuose.

Šios eilutės paimtos iš tinklo tinklo ir čia pradžia su sąlyga atrodo pernelyg sudėtinga, susidedanti iš daugybės įvykių, būtent - vietinių failų sistemos , udevtrigger , konteineris , vykdymo lygis , tinklas .

Vietines failų sistemas skleidžia mountall, udevtrigger yra darbo pavadinimas, konteinerio įvykį - konteinerio aptikimas, runlevel įvykį, kurį skleidžia rc-sysinit, ir tinklas vėl yra darbas.

Taigi hierarchijoje proceso tinklas yra „mountall“, „udevtrigger“ ir „container-aptikti“ pakaitalas, nes jis negali tęsti savo veikimo (proceso veikimas yra visos eilutės, apibrėžtos scenarijaus ar vykdymo sekcijose proceso konfigūracijos faile). kol pirmiau minėti procesai sugeneruos jų įvykius.
Panašiai mes galime turėti vieną procesą kaip daugelio tėvą, jei vieno proceso sugeneruotą įvykį talpina daugelis.

Kaip apibrėžta anksčiau, mes galime turėti trumpalaikius (arba darbas ir mirimas darbus) arba ilgą gyvenimą (arba buvimas ir darbas ), bet kaip atskirti juos??

Darbai, kurių sąlygos „ prasideda “ ir „ sustoja “, nurodytos jų konfigūracijos failuose, ir jų žodyje yra „ užduotis “ konfigūracijos failas yra darbas ir mirti užduotys, kurios prasideda sugeneruotame įvykyje, vykdo scenarijų ar vykdymo sekciją (vykdydami blokuoja įvykius, kurie juos sukėlė) ir miršta po to, kai išleidžia tuos įvykius, kuriuos užblokavo .

Tie darbai, kurių konfigūracijos faile nėra „ sustabdykite “ sąlygos, yra ilgai gyvuojantys arba likite ir dirbkite darbai ir jie niekada nemiršta. Dabar darbo vietoje buvimo ir darbo vietos gali būti klasifikuojamos taip:

1. Tie, kurie neturi atkūrimo sąlygų ir kuriuos gali nužudyti šakninis vartotojas.
2. Tie, kurių konfigūracijos faile yra iš naujo paleista sąlyga, todėl nužudyti jie paleidžiami iš naujo, nebent jų darbas buvo baigtas.

Išvada

Taigi kiekvienas LINUX procesas yra priklausomas nuo kai kurių ir turi nuo jo priklausomus procesus, o šis ryšys yra daug iš daugelio ir nurodomas su paleidimo sistema kartu su kitomis proceso detalėmis.