Globoki vpogledi v sistem "Ubuntu Linux" - ali to vidimo?

LINUX , kot ga poznamo, je jedro in ne operacijski sistem, ima več distribucij, kot so: Debian, Fedora, Ubuntu itd. in še veliko več. Ubuntu OS, ki ga je razvil Mark Shuttleworth, je v javnosti znan in ga mnogi pogosto uporabljajo. Tudi nova različica, ki je brezplačna in odprtokodna, izide vsako leto, k čemur prispeva na tisoče razvijalcev, ki prispevajo k njenemu razvoju. Kako pa deluje? Kateri vsi procesi, seznam dogodkov omogočajo njegovo delovanje in kakšen je pomen teh procesov?

Ta članek vas bo poglobil v notranjost Ubuntu OS , ki je zelo zanimiva in bo novincem pomagala, da bodo popolnoma razumeli njeno delovanje.

Položite sistem

Linux ima postopek za svoje delovanje, vsaka sistemska storitev, vključno z upravljanjem porabe, zagonom, ravnanjem z zrušitvami sistema, je postopek, ki ima v\"/etc/init " konfiguracijsko datoteko, ki opisuje dogodek v ki jo bo izvedel in ustrezen dogodek, na katerem bi ustavil njegovo izvajanje, skupaj s tem pa vzdržuje tudi druge konfiguracijske datoteke, ki opisujejo njegovo obnašanje v imeniku sistema\"/etc/", s čimer da sistem postane dogodek.

Če se ustvarijo dogodki, bi moral biti nekdo tam, da jih ujame in izvrši ?? No, očitno je krmilnik naš glavni proces, ki obstaja kot nadrejeni za vse procese z ID-jem postopka 1 , tj. init . To je postopek, ki se začne z zagonom sistema in se nikoli ne ustavi. Ta postopek umre šele, ko sistem izklopi, saj ni nobenega procesa, ki bi bil nadrejeni init

Prejšnje različice Ubuntuja pred 6.10 so vključevale stari slog sysvinit , ki je bil uporabljen za izvajanje skriptov v\" /etc/rcx.d ”pri vsakem zagonu in zaustavitvi sistema. Po tem pa je sistem upstart zamenjal sistem starega sloga sysvinit , vendar še vedno zagotavlja združljivost z njim.

Najnovejše različice Ubuntu imajo ta sistem za nadgrajevanje, vendar je od njegovega razvoja od Ubuntu 6.10 potekal več revizij, trenutna različica pa je bila 1.13.2 4. septembra 2014. ima 2 init procesa, enega za sistemske procese in drugega, ki upravlja trenutno prijavljeno uporabniško sejo in obstaja le do prijave uporabnika, imenovano tudi x-session init .

Celoten sistem je bil postavljen kot hierarhičen sistem, ki je sestavljen iz odnosa prednik-otrok v celotni moči do izpada sistema.

Na primer : Majhna hierarhična povezava med obema procesoma init je: sistem init (1) -> upravitelj zaslona (prostor jedra) -> upravitelj zaslona (uporabniški prostor) -> uporabniški init (ali x- seja init).

Konfiguracijske datoteke za procese, ki jih upravlja sistem init, se nahajajo v\"/etc/init " in za tiste, ki jih upravlja init seje, se nahajajo v\"/usr/share/upstart " (v skladu s trenutno nadgrajenimi različicami nad 1.12 ) in te konfiguracijske datoteke so ključne za številne odkrite skrivnosti o procesih, kot je opisano v tem članku.

Poglobiti se v hierarhijo

Ubuntu prepozna dve vrsti procesov:

1. Kratkotrajna delovna mesta (ali dela, ki delajo in umrejo).
2. Dolgotrajna delovna mesta (ali dela, ki ostanejo in delajo).

Hierarhija, ki je narejena v sistemu, je posledica razmerja odvisnosti med procesi, ki ga lahko razumemo z ogledom njihovih konfiguracijskih datotek. Začnimo najprej s preprostega hierarhičnega razmerja med procesi, zaradi katerih se sistem zažene, in razumemo pomen vsakega od njih.

Init je prvi postopek, ki se začne ob vklopu sistema, in je razvrščen kot delo-in-bivanje , ker ni nikoli umorjen in je vklopljen le čas, ko je vklopljen izklop, tj. init umre le enkrat, in to tudi enkrat na sejo, to pa je izklop. Ob vklopu init ustvari prvi dogodek v sistemu, to je zagonski dogodek. Vsaka konfiguracijska datoteka v\"/etc/init " ima dve vrstici, ki določata dogodek, zaradi katerega se postopek zažene in ustavi. Te vrstice so označene na spodnji sliki:

To je konfiguracijska datoteka procesa failsafe-x , ki se zažene in ustavi pod pogoji, ki opisujejo dogodek, v katerem se bo postopek začel. Ob generiranju zagonskega dogodka s procesom init se vzporedno izvajajo tisti procesi, ki imajo zagon kot pogoj, kar določa le hierarhijo, vsi procesi, ki se izvajajo ob zagonu, pa so otroci init.

Procesi, ki se zaženejo ob zagonu, so navedeni pod in to so vsa delovna mesta:

1 . ime gostitelja - to je postopek, ki sistemu pove samo njegovo ime gostitelja, določeno v datoteki/etc/hostname.

2 . kmod - Naloži module jedra, tj. vse gonilnike iz datoteke/etc/modules.

3 . mounttall - Ta postopek ustvari veliko dogodkov in je v glavnem odgovoren za iskanje vseh datotečnih sistemov ob zagonu, vključno z lokalnimi datotečnimi sistemi in oddaljenimi datotečnimi sistemi.

Datoteka /proc je prav tako nameščena s tem postopkom in po vseh montažnih delih je zadnji dogodek, ki ga ustvari, dogodek datotečnih sistemov, zaradi česar je hierarhija nadaljevana.

4 . plymouth - Ta postopek se izvede ob zagonu mount in je odgovoren za prikaz tistega črnega zaslona, ki je viden ob zagonu sistema in prikazuje nekaj takega spodaj:

5 . pripravljen za plymouth - Označuje, da je plymouth vpet.

Sledijo glavni procesi, drugi, ki se prav tako izvajajo ob zagonu, na primer udev-backupback-graphics itd. Če se vrnemo v hierarhijo zagona, na kratko dogodki in procesi, ki sledijo, sledijo zaporedju:

1 . init skupaj z generacijo zagonskega dogodka.

2 . Mountall montažni datotečni sistemi, plymouth (skupaj z zagonom mounttall), ki prikaže začetni zaslon, in moduli za nalaganje jedra kmod.

3 . dogodek lokalnega datotečnega sistema , ki ga je ustvaril Mountall in povzročil zagon dbusa. (Dbus je sistemsko vodilo za sporočila, ki ustvari vtičnico, ki omogoča, da drugi procesi komunicirajo med seboj prek pošiljanja sporočil v to vtičnico, sprejemnik pa posluša sporočila v tej vtičnici in filtrira tista, ki so zanj namenjena).

4 . lokalni datotečni sistem skupaj z zagnanim dbusom in dogodkom statičnega omrežja, ki ga povzroči procesno omrežje, ki se izvaja tudi na dogodku lokalnega datotečnega sistema, povzroči zagon upravitelja omrežja.

5 . Dogodek navideznega datotečnega sistema , ki ga generira Mountall, povzroči udev za zagon. (udev je upravitelj naprav za linux, ki upravlja vroče priključevanje naprav in je odgovoren za ustvarjanje datotek v imeniku/dev in njihovo upravljanje.) udev ustvari datoteke za ram, rom itd. v imeniku/dev, ki jih je mounttall dokončal -filesystems in je ustvaril dogodek virtualni-datotečni sistem, ki pomeni namestitev imenika/dev.

6 . udev povzroči zagon upstart-udev-bridge, kar pomeni, da je lokalno omrežje vklopljeno. Potem, ko je Mountall končal namestitev zadnjega datotečnega sistema in ustvaril dogodek datotečnega sistema.

7 . Dogodek datotečnega sistema skupaj z dogodkom statičnega omrežja povzroči zagon opravila rc-sysinit. Tu prihaja nazaj združljivost med starejšimi sysvinit in upstart ...

9 . rc-sysinit zažene ukaz telinit, ki sporoča sistemski ravni.

10 . Po pridobitvi ravni izvajanja init izvede skripte, ki se začnejo s 'S' ali 'K' (začetna opravila, ki imajo na začetku imena 'S' in ubijo tiste, ki imajo 'K' na začetku svojega imena) v imeniku/etc/rcX.d (kjer je 'X' trenutna stopnja izvajanja).

Ta majhen niz dogodkov povzroči, da se sistem zažene vsakič, ko ga vklopite. In ta dogodek, ki sproži procese, je edina stvar, ki je odgovorna za ustvarjanje hierarhije.

Zdaj je še en dodatek zgoraj vzrok za dogodek. Kateri postopek povzroči, kateri dogodek je naveden tudi v isti konfiguracijski datoteki procesa, kot je prikazano spodaj v teh vrsticah:

Zgoraj je razdelek konfiguracijske datoteke procesa mount. To prikazuje dogodke, ki jih oddaja. Ime dogodka je naslednik besede " dogodek ". Dogodek je lahko tisti, ki je definiran v konfiguracijski datoteki, kot je opisano zgoraj, ali pa je lahko ime procesa skupaj s predpono "zagon", "zagon", "zaustavitev" ali "zaustavitev".

Torej, tukaj definiramo dva izraza:

1. Generator dogodkov : Tisti, ki ima v svoji konfiguracijski datoteki vrstico 'emits xxx', kjer je xxx ime dogodka, ki ga ima v lasti ali ustvari.
2. Lovilec dogodkov : Tisti, ki ima začetek ali zaustavitev kot xxx ali ki se začne ali ustavi na dogodku, ki je ustvaril enega od generatorjev dogodkov.

Tako sledi hierarhija in tako odvisnost med procesi:

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

Do zdaj ste že razumeli, kako je hierarhija odvisnosti starša in otroka med procesi določena z mehanizmom sprožitve dogodkov s preprostim mehanizmom za zagon.

Zdaj ta hierarhija nikoli ni odnos ena na ena, ki ima samo enega starša za enega otroka. V tej hierarhiji imamo lahko enega ali več staršev za enega otroka ali pa je en proces starš več kot enega otroka. Kako se to doseže ?? No, odgovor je v samih konfiguracijskih datotekah.

Te vrstice so vzete iz procesa - mreženje in tukaj se zdi, da je začetek pod pogojem preveč zapleten, sestavljen iz veliko dogodkov, in sicer - lokalni-datotečni sistemi , udevtrigger , vsebnik , runlevel , mreženje .

Lokalni datotečni sistem oddaja Mountall, udevtrigger je ime opravila, dogodek vsebnika oddaja zaznavanje vsebnika, dogodek stopnje teka oddaja rc-sysinit in mreženje je spet opravilo.

Tako je v hierarhiji procesno mreženje podrejeno Mountall, Udevtrigger in zaznavanju vsebnikov, saj ne more nadaljevati svojega delovanja (delovanje procesa so vse vrstice, ki so opredeljene v odsekih skripta ali izvršnih datotek v konfiguracijski datoteki procesa) dokler zgoraj navedeni procesi ne ustvarijo svojih dogodkov.
Prav tako imamo lahko en proces nadrejen mnogim, če je dogodek, ki ga ustvari en proces, predpomnil več.

Kot smo že opredelili, imamo lahko bodisi kratkotrajna (ali dela in dela delo) bodisi dolgoživa (ali ostanemo in delamo ), vendar kako razlikovati med njim??

Opravila, ki imajo v svojih konfiguracijskih datotekah pogoje » zaženi « in » ustavi se «, v svojih besedah pa je beseda »opravilo « konfiguracijska datoteka so dela-in-umri opravila, ki se zaženejo na ustvarjenem dogodku, izvedejo svoj skript ali izvršilni odsek (med izvajanjem blokirajo dogodke, ki so jih povzročili) in nato umrejo, sprostijo tiste dogodke, ki so jih blokirali .

Tista opravila, ki v svoji konfiguracijski datoteki nimajo pogoja „ ustavi se «, so dolga ali ostanejo in delajo in nikoli ne umrejo. Zdaj lahko delovna mesta, ki ostanejo in delajo, razvrstimo še naprej:

1. Tiste, ki nimajo stanja ponovnega vzpona in jih lahko root uporabnik ubije.
2. Tisti, ki so se v svoji konfiguracijski datoteki obnovili in se po umoru znova zaženejo, razen če je njihovo delo končano.

Zaključek

Tako je vsak postopek v LINUX-u odvisen od nekaterih, nekateri procesi pa so odvisni od njega, to razmerje pa je veliko pri mnogih in je določeno s sistemom za zagon, skupaj z drugimi podrobnostmi procesa.