Diepe inzichten in het "Ubuntu Linux"-systeem - zien we dit?

LINUX zoals we weten is een kernel en geen besturingssysteem, wordt geleverd met verschillende distributies zoals: Debian, Fedora, Ubuntu sterk> enz. en nog veel meer. Ubuntu OS ontwikkeld door Mark Shuttleworth is in de volksmond bekend en wordt door velen veel gebruikt. Omdat het gratis en open source is, wordt er jaarlijks een nieuwe versie uitgebracht, die wordt bijgedragen door duizenden ontwikkelaars die bijdragen aan de ontwikkeling ervan. Maar hoe werkt het? Welke processen, lijst met gebeurtenissen zorgen ervoor dat het werkt en wat is de betekenis van deze processen?

Dit artikel gaat dieper in op de interne onderdelen van Ubuntu OS, die erg interessant zijn en die een beginneling kunnen helpen een volledig begrip te krijgen van de werking ervan.

Leg het systeem neer

Linux heeft een proces voor het functioneren ervan, elke systeemservice, inclusief energiebeheer, opstarten, afhandeling van systeemcrashes is een proces met een configuratiebestand in “/etc/init” dat de gebeurtenis beschrijft waarop het zal een overeenkomstige gebeurtenis uitvoeren waarop het de uitvoering ervan zou stoppen, daarnaast onderhoudt het ook zijn andere configuratiebestanden die het runtime-gedrag beschrijven in de map “/etc/ ” van het systeem, waardoor het systeem een gebeurtenisgestuurde.

Als er gebeurtenissen worden gegenereerd, moet er dan iemand aanwezig zijn om deze op te vangen en uit te voeren? Het is duidelijk dat de controller ons hoofdproces is, dat bestaat als ouder van alle processen met proces-id 1, d.w.z. init. Dit is het proces dat begint met het opstarten van het systeem en nooit stopt. Dit proces sterft pas af als het systeem wordt uitgeschakeld, omdat er geen proces is dat de ouder is van init.

Eerdere versies van Ubuntu vóór 6.10 bevatten sysvinit in oude stijl, dat werd gebruikt om scripts uit te voeren in “/etc/rcx.d b> ” map bij elke opstart en afsluiting van het systeem. Maar daarna verving het upstart-systeem het sysvinit-systeem in de oude stijl, maar biedt het nog steeds achterwaartse compatibiliteit.

De nieuwste Ubuntu-versies hebben dit nieuwe systeem, maar sinds de evolutie van Ubuntu 6.10 zijn er verschillende herzieningen geweest, de huidige versie is 1.13.2 op 4 september 2014. Het nieuwste nieuwe systeem heeft 2 init processen, één voor de systeemprocessen en een andere die de huidige ingelogde gebruikerssessie beheert en bestaat alleen totdat de gebruiker is ingelogd, ook wel x-session init genoemd .

Het hele systeem is hiërarchisch vastgelegd, bestaande uit een voorouder-kindrelatie gedurende de periode dat het systeem op- en afschakelt.

Bijvoorbeeld: een kleine hiërarchische relatie tussen beide init-processen is: system init(1) -> display manager(kernelruimte) -> display manager (gebruikersruimte) -> gebruiker init (of x-sessie init).

De configuratiebestanden voor processen die worden beheerd door system init bevinden zich in “/etc/init ” en voor processen die worden beheerd door session init bevinden zich in “/usr/share/upstart ” (zoals volgens de huidige nieuwe versies boven 1.12) en deze configuratiebestanden zijn de sleutel tot veel opgegraven geheimen over processen zoals beschreven in dit artikel.

Steeds dieper in de Hiërarchie komen

Ubuntu herkent twee soorten processen:

1. Banen met een korte levensduur (of werk-en-sterf-banen).
2. Langlevende banen (of ‘blijf-en-werk-banen’).

De hiërarchie die op het systeem wordt gemaakt, is te wijten aan de afhankelijkheidsrelatie tussen processen, die we kunnen begrijpen door hun configuratiebestanden te bekijken. Laten we eerst uitgaan van een eenvoudige hiërarchische relatie tussen de processen die ervoor zorgen dat het systeem opstart en de betekenis van elk ervan begrijpen.

Opstarthiërarchie

Init is het eerste proces dat begint bij het inschakelen van het systeem en is geclassificeerd onder werk-en-blijf-taak, omdat het nooit wordt beëindigd en alleen het moment waarop de init wordt beëindigd, is ingeschakeld bij het uitschakelen, d.w.z. init sterft alleen en dat ook één keer per sessie en dat is bij het uitschakelen. Bij het opstarten genereert init de allereerste gebeurtenis op het systeem, d.w.z. de opstartgebeurtenis. Elk configuratiebestand in “/etc/init ” heeft twee regels die de gebeurtenis definiëren die ervoor zorgt dat het proces start en stopt. Deze lijnen zijn zoals gemarkeerd in de onderstaande afbeelding:

Dit is een configuratiebestand van een proces failsafe-x en deze start- en stop-op-voorwaarden beschrijven de gebeurtenis waarop het proces zal starten. Bij het genereren van een opstartgebeurtenis door het init-proces worden de processen die opstarten als start-on-voorwaarde hebben, parallel uitgevoerd en dit definieert alleen de hiërarchie, en alle processen die bij het opstarten worden uitgevoerd, zijn kinderen van init.

De processen die bij het opstarten beginnen, worden vermeld zoals hieronder en dit zijn allemaal werk-en-die-taken:

1. hostnaam – Dit is een proces dat het systeem alleen vertelt over de hostnaam die is gedefinieerd in het bestand /etc/hostname.

2. kmod – Laadt de kernelmodules, d.w.z. alle stuurprogramma's uit het bestand /etc/modules.

3. mountall – Dit proces genereert veel gebeurtenissen en is voornamelijk verantwoordelijk voor het aankoppelen van alle bestandssystemen tijdens het opstarten, inclusief lokale bestandssystemen en externe bestandssystemen.

Het bestand /proc wordt ook door dit proces aangekoppeld en na al het montagewerk is de laatste gebeurtenis die erdoor wordt gegenereerd een bestandssysteemgebeurtenis, waardoor de hiërarchie verder gaat.

4. plymouth – Dit proces wordt uitgevoerd bij het starten van mountall en is verantwoordelijk voor het tonen van het zwarte scherm dat te zien is bij het opstarten van het systeem, met iets als hieronder:

5. plymouth-ready – Geeft aan dat Plymouth actief is.

Hieronder volgen de hoofdprocessen, andere die ook worden uitgevoerd bij het opstarten zijn onder meer udev-fallback-graphics, enz. Terugkomend op de opstarthiërarchie: in een notendop zijn de gebeurtenissen en processen die volgen als volgt:

1. init samen met het genereren van een opstartgebeurtenis.

2. mountall aankoppelen van bestandssystemen, plymouth (samen met het starten van mountall) dat het opstartscherm weergeeft, en kmod die kernelmodules laadt.

3. local-filesystem gebeurtenis gegenereerd door mountall waardoor dbus wordt uitgevoerd. (Dbus is de systeembrede berichtenbus die een socket creëert waarmee andere processen met elkaar kunnen communiceren door berichten naar deze socket te sturen en de ontvanger luistert naar de berichten op deze socket en filtert de berichten die ervoor bedoeld zijn).

4. local-filesystem samen met gestarte dbus en static-network-up gebeurtenis veroorzaakt door het procesnetwerk dat ook draait op local-filesystem gebeurtenis zorgt ervoor dat netwerkmanager wordt uitgevoerd.

5. virtual-filesystem gebeurtenis gegenereerd door mountall zorgt ervoor dat udev wordt uitgevoerd. (udev is de apparaatbeheerder voor Linux die hot-plugging van apparaten beheert en verantwoordelijk is voor het maken van bestanden in de map /dev en deze ook beheert.) udev maakt bestanden aan voor ram, rom enz. in de map /dev waar de mountall klaar is met het virtueel mounten -filesystems en heeft de gebeurtenis virtual-filesystem gegenereerd, wat het aankoppelen van de map /dev aangeeft.

6. udev zorgt ervoor dat upstart-udev-bridge wordt uitgevoerd, wat aangeeft dat het lokale netwerk actief is. Vervolgens nadat mountall het laatste bestandssysteem heeft aangekoppeld en een bestandssysteemgebeurtenis heeft gegenereerd.

7. De gebeurtenis filesystem en de gebeurtenis static-network-up zorgen ervoor dat de taak rc-sysinit wordt uitgevoerd. Hier komt de achterwaartse compatibiliteit tussen oudere sysvinit en parvenu...

9. rc-sysinit voert de telinit-opdracht uit die het systeemrunlevel vertelt.

10. Nadat het runlevel is verkregen, voert de init de scripts uit die beginnen met 'S' of 'K' (start taken met 'S' in begin van hun naam en het doden van degenen met 'K' aan het begin van hun naam) in de map /etc/rcX.d (waar 'X' het huidige runlevel is) .

Deze kleine reeks gebeurtenissen zorgt ervoor dat het systeem elke keer dat u het inschakelt, start. En deze gebeurtenis die processen in gang zet, is het enige dat verantwoordelijk is voor het creëren van de hiërarchie.

Een andere aanvulling op het bovenstaande is de oorzaak van de gebeurtenis. Welk proces welke gebeurtenis veroorzaakt, wordt ook gespecificeerd in datzelfde configuratiebestand van het proces, zoals hieronder weergegeven in deze regels:

Hierboven ziet u een sectie van het configuratiebestand van proces mountall. Dit toont de gebeurtenissen die het uitzendt. De naam van het evenement is de naam die volgt op het woord ‘evenement’. De gebeurtenis kan degene zijn die is gedefinieerd in het configuratiebestand zoals hierboven, of kan de naam van het proces zijn, samen met het voorvoegsel ‘starten’, ‘gestart’, ‘stoppen’ of ‘gestopt’.

Hier definiëren we dus twee termen:

1. Gebeurtenisgenerator: een generator met de regel 'emits xxx' in het configuratiebestand, waarbij xxx de naam is van de gebeurtenis die hij bezit of genereert.
2. Event Catcher: een gebeurtenis waarvan de start- of stopvoorwaarde xxx is, of die start of stopt op de gebeurtenis die door een van de gebeurtenisgeneratoren is gegenereerd.

De hiërarchie volgt dus en dus de afhankelijkheid tussen processen:

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

Complexiteit toevoegen aan de hiërarchie

Tot nu toe moet u hebben begrepen hoe de hiërarchie van ouder-kind afhankelijkheid tussen de processen wordt vastgelegd door een gebeurtenistrigger-mechanisme via een eenvoudig opstartmechanisme.

Deze hiërarchie is nooit een één-op-één-relatie met slechts één ouder voor één kind. In deze hiërarchie kunnen we één of meer ouders hebben voor één kind, of één proces waarbij we ouder zijn van meer dan één kind. Hoe wordt dit gerealiseerd?? Het antwoord ligt in de configuratiebestanden zelf.

Deze regels zijn afkomstig uit proces-netwerken en hier lijkt de start-op-voorwaarde iets te complex en bestaat uit veel gebeurtenissen, namelijk – lokale bestandssystemen, udevtrigger, container, runlevel, netwerken.

Lokale bestandssystemen worden verzonden door mountall, udevtrigger is de naam van de taak, de containergebeurtenis wordt verzonden door container-detect, de runlevel-gebeurtenis wordt verzonden door rc-sysinit, en netwerken is opnieuw een taak.

In een hiërarchie is het procesnetwerk dus een kind van mountall, udevtrigger en container-detect omdat het zijn werking niet kan voortzetten (het functioneren van het proces bestaat uit alle regels die zijn gedefinieerd onder script- of exec-secties in het configuratiebestand van het proces) totdat de bovenstaande processen hun gebeurtenissen genereren.
Op dezelfde manier kunnen we één proces de ouder van vele processen laten zijn als de gebeurtenis die door één proces wordt gegenereerd, door velen in de cache wordt opgeslagen.

Onderscheidende soorten banen

Zoals eerder gedefinieerd, kunnen we banen van korte duur (of werk-en-sterf) of langlevende banen (of blijf-en-werk) banen hebben, maar hoe kunnen we onderscheid maken tussen hen??

De taken waarvoor zowel de voorwaarden 'start op' als 'stop op' zijn gespecificeerd in hun configuratiebestanden en die het woord 'taak' in hun configuratiebestand zijn work-and-die-taken die beginnen bij de gegenereerde gebeurtenis, hun script of exec-sectie uitvoeren (tijdens het uitvoeren blokkeren ze de gebeurtenissen die deze hebben veroorzaakt) en sterven daarna af, waarbij de gebeurtenissen worden vrijgegeven die ze hebben geblokkeerd .

De banen die niet de voorwaarde ‘stoppen’ in hun configuratiebestand hebben, zijn banen met een lange levensduur of blijf-en-werken-banen en ze sterven nooit. Nu kunnen de verblijfs- en werkbanen verder worden geclassificeerd als:

1. Degenen die geen respawn-voorwaarde hebben en kunnen worden gedood door de rootgebruiker.
2. Degenen die een respawn-voorwaarde in hun configuratiebestand hebben en dus opnieuw opstarten nadat ze zijn gedood, tenzij hun werk is voltooid.

Conclusie

Elk proces in LINUX is dus afhankelijk van sommigen en sommige processen zijn ervan afhankelijk. Deze relatie is talrijk en wordt gespecificeerd met het beginnende systeem, samen met andere details van het proces.