Dyb indsigt i "Ubuntu Linux" -systemet - ser vi dette?

LINUX som vi ved er en kerne og ikke et operativsystem, sendes med flere distributioner som: Debian, Fedora, Ubuntu osv. og mange flere. Ubuntu OS udviklet af Mark Shuttleworth er populært kendt og udbredt af mange. Da den er gratis og Open Source, udgives den nye version årligt, som er bidraget af tusindvis af udviklere, der bidrager til dens udvikling. Men hvordan fungerer det? Hvad alle processer, liste over begivenheder får det til at fungere, og hvad er betydningen af disse processer?

Denne artikel vil tage dig lidt dybt ind i internt i Ubuntu OS , der er meget interessante og vil hjælpe en novice med at få en fuldstændig forståelse af dens funktion.

Læg systemet ned

Linux har en proces til sin funktion, hver systemtjeneste inklusive strømstyring, opstart, systemnedbrudshåndtering er en proces, der har en konfigurationsfil i "/etc/init ", der beskriver begivenhed, hvorpå det vil udføre og tilsvarende begivenhed, hvormed det ville stoppe dets udførelse, sammen med at det også vedligeholder sine andre konfigurationsfiler, der beskriver dets kørselstidsadfærd i systemets "/etc/" bibliotek, hvilket gør systemet en begivenhedsdrevet en.

Hvis der genereres begivenheder, skal nogen være der for at fange dem og udføre dem ?? Nå er det tydeligt, at controlleren er vores hovedproces, der findes som overordnet til alle processer med proces-id 1 dvs. init . Dette er den proces, der starter med systemets opstart og aldrig stopper. Denne proces dør først, når systemet er slået fra, da der ikke er nogen proces, der er forælder til init.

Tidligere versioner af Ubuntu før 6.10 inkluderede gammel stil sysvinit , der blev brugt til at køre scripts i “ /etc/rcx.d ”-mappe ved hver opstart og nedlukning af systemet. Men derefter erstattede upstart systemet det gamle sysvinit -system, men giver stadig bagudkompatibilitet til det.

De nyeste Ubuntu-versioner har dette upstart-system, men siden dets udvikling fra Ubuntu 6.10 er der gået flere versioner, den nuværende version er 1.13.2 pr. 4. september 2014. Det seneste upstart-system har 2 init processer, en til systemprocesserne og en anden, der administrerer den aktuelle loggede brugersession og eksisterer kun, indtil brugeren er logget ind, også kaldet x-session init .

Hele systemet er blevet fastlagt som et hierarkisk system, der består af forfædre-barn-forhold i hele magt op til nedlukning af systemet.

For eksempel : En lille hierarkisk relation mellem begge init-processerne er: system init (1) -> display manager (kernel space) -> display manager (user space) -> user init (eller x- session init).

Konfigurationsfilerne til processer, der administreres af systeminit, ligger i “/etc/init ” og for dem, der administreres af sessioninit, ligger i “/usr/share/upstart ” (som pr. de aktuelle upstart-versioner over 1.12 ), og disse konfigurationsfiler er nøglen til mange udgravede hemmeligheder om processer som beskrevet i denne artikel.

At blive mere dybere ind i hierarkiet

Ubuntu genkender to typer processer:

Kortvarige job (eller arbejde-og-dø-job).
Langlevede job (eller opholds- og arbejdsjob).

Hierarkiet, der er lavet på systemet, skyldes afhængighedsforholdet mellem processer, som vi kan forstå ved at se deres konfigurationsfiler. Lad os først starte med et simpelt hierarkisk forhold mellem de processer, der får systemet til at starte og forstå betydningen af hver af dem.

Init er den første proces, der starter med at tænde for systemet og er klassificeret under arbejde-og-ophold job, da det aldrig dræbes, og den eneste gang init dræbes er tændt afbrydelse dvs. init dør kun, og det også en gang pr. session, og det er ved afbrydelse. Ved opstart genererer init den allerførste begivenhed på systemet, dvs. opstartshændelse. Hver konfigurationsfil i “/etc/init ” har to linjer, der definerer den begivenhed, der får processen til at starte og stoppe. Disse linjer er som fremhævet i nedenstående figur:

Dette er en konfigurationsfil af en proces failsafe-x , og disse starter og stopper under betingelser, der beskriver den begivenhed, hvor processen starter. Ved generering af opstartshændelse efter init-proces udføres de processer, der har opstart som start på betingelse, parallelt, og dette definerer kun hierarkiet, og alle de processer, der udføres ved opstart, er børn af init.

De processer, der starter ved opstart, er angivet som under, og disse er alle arbejds-og-dø-job:

1 . værtsnavn - Dette er en proces, der bare fortæller systemet om dets værtsnavn, der er defineret i/etc/værtsfil.

2 . kmod - Indlæser kernemodulerne, dvs. alle driverne fra/etc/modules-filen.

3 . mountall - Denne proces genererer mange begivenheder og er hovedsagelig ansvarlig for at montere alle filsystemer ved opstart inklusive lokale filsystemer og eksterne filsystemer.

/proc -filen er også monteret ved netop denne proces, og efter alt monteringsarbejdet er den sidste begivenhed, der er genereret af den, filsystemhændelse, hvilket yderligere får hierarkiet til at gå videre.

4 . plymouth - Denne proces udføres ved start af mountall og er ansvarlig for at vise den sorte skærm, der ses ved systemstart, der viser noget som nedenfor:

5 . plymouth-klar - Angiver, at plymouth er oppe.

Følgende er hovedprocessen, andre, der også udføres ved opstart, inkluderer f.eks. udev-fallback-grafik osv. Kommer tilbage til boothierarkiet, i en nøddeskal er begivenhederne og processerne, der følger, som i rækkefølge:

1 . init sammen med generering af opstartshændelse.

2 . mountall montering af filsystemer, plymouth (sammen med start-mountall), der viser stænkskærmen og kmod loading kernemoduler.

3 . lokalt filsystem begivenhed genereret af mountall, der får dbus til at køre. (Dbus er den systemdækkende meddelelsesbus, der skaber en sokkel, der lader andre processer kommunikere til hinanden ved at sende meddelelser til dette stik, og modtageren lytter efter meddelelserne på dette stik og filtrerer dem, der er beregnet til det).

4 . lokalt filsystem sammen med startet dbus og statisk netværks-up-begivenhed forårsaget af procesnetværket, der også kører på et lokalt filsystem-arrangement, får netværksadministrator til at køre.

5 . virtuelt filsystem begivenhed genereret af mountall får udev til at køre. (udev er enhedsadministrator til linux, der administrerer hot-plugging af enheder og er ansvarlig for at oprette filer i/dev-biblioteket og administrere dem også.) udev opretter filer til ram, rom osv. i/dev-kataloger, som mountall er færdig med at montere virtuelt -filsystemer og har genereret begivenheden virtuelt filsystem, der betyder montering af/dev-kataloget.

6 . udev får kører upstart-udev-bridge, der betyder, at det lokale netværk er op. Derefter, efter mountall er færdig med at montere det sidste filsystem og har genereret filsystemhændelse.

7 . filsystem begivenhed sammen med statisk netværks-up begivenhed får rc-sysinit job til at køre. Her kommer bagudkompatibiliteten mellem ældre sysvinit og upstart ...

9 . rc-sysinit kører telinit-kommando, der fortæller systemets kørselsniveau.

10 . Efter at få runlevel udfører init de scripts, der starter med 'S' eller 'K' (start job, der har 'S' i begyndelsen af deres navn og dræber dem, der har 'K' i begyndelsen af deres navn) i biblioteket/etc/rcX.d (hvor 'X' er det aktuelle køreplan).

Dette lille sæt begivenheder får systemet til at starte hver gang du tænder det. Og denne begivenhedsudløsning af processer er den eneste ting, der er ansvarlig for at skabe hierarkiet.

Nu er en anden tilføjelse til ovenstående årsagen til begivenheden. Hvilken proces der forårsager hvilken begivenhed er også specificeret i den samme konfigurationsfil af processen som vist nedenfor i disse linjer:

Ovenfor er et afsnit af konfigurationsfilen til procesmontering. Dette viser de begivenheder, det udsender. Navnet på begivenheden er en efterfølgende ordet ' begivenhed '. Begivenheden kan enten være den, der er defineret i konfigurationsfilen som ovenfor eller kan være navnet på processen sammen med præfikset 'start', 'startet', 'stop' eller 'stoppet'.

Så her definerer vi to udtryk:

Begivenhedsgenerator : En, der har linjen 'udsender xxx' i sin konfigurationsfil, hvor xxx er navnet på den begivenhed, den ejer eller genererer.
Event Catcher : En, der har sin start på eller stop-tilstand som xxx, eller som starter eller stopper ved begivenheden genereret en af begivenhedsgeneratorerne.

Således følger hierarkiet, og afhængigheden mellem processer er således:

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

Indtil nu skal du have forstået, hvordan hierarkiet af forældre-barn afhængighed mellem processerne er fastlagt ved begivenhedsudløsende mekanisme gennem en simpel opstartsmekanisme.

Nu er dette hierarki aldrig et en-til-en-forhold, der kun har en forælder til et barn. I dette hierarki kan vi have en eller flere forældre til et barn, eller en proces er at være forælder til mere end et barn. Hvordan dette opnås? Svaret ligger godt i selve konfigurationsfilerne.

Disse linjer er taget fra procesnetværk og her virker start på betingelse lidt for kompleks sammensat af mange begivenheder, nemlig - lokale filsystemer , udevtrigger , container , runlevel , networking .

Lokale filsystemer udsendes af mountall, udevtrigger er navnet på jobbet, containerhændelse udsendes af container-detect, runlevel-begivenhed udsendt af rc-sysinit, og netværk er igen et job.

I et hierarki er procesnetværket således underordnet af mountall, udevtrigger og container-detect, da det ikke kan fortsætte med at fungere (procesens funktion er alle de linjer, der er defineret under script eller exec-sektioner i konfigurationsfilen til processen) indtil de ovennævnte processer genererer deres begivenheder.
På samme måde kan vi have en proces, der er forælder til mange, hvis begivenheden genereret af en proces caches af mange.

Som defineret tidligere kan vi have enten kortvarige (eller arbejde-og-dø job) eller langvarige (eller ophold-og-arbejde ) job, men hvordan man skelner mellem dem??

De job, der har både ' start på ' og ' stopper under ' betingelser, der er specificeret i deres konfigurationsfiler, og som har ordet ' opgave ' i deres konfigurationsfil er job-and-die job, der starter på den genererede begivenhed, udfører deres script eller exec-sektion (mens de udføres, blokerer de begivenhederne, der forårsagede dem) og dør bagefter og frigiver de begivenheder, som de blokerede .

De job, der ikke har " stop på " -tilstand i deres konfigurationsfil, er langvarige eller ophold og arbejde job, og de dør aldrig. Nu kan opholds- og arbejdsjobbet klassificeres yderligere som:

Dem, der ikke har respawn-tilstand og kan dræbes af root-brugeren.
Dem, der har respawn-tilstand i deres konfigurationsfil, og derfor genstarter de, når de er dræbt, medmindre deres arbejde er afsluttet.

Konklusion

Således er hver proces i LINUX afhængig af nogle og har nogle processer afhængig af den, og dette forhold er mange for mange og er specificeret med upstart-systemet sammen med andre detaljer i processen.