Deep Abléck vum Ubuntu Linux System - Gesinn mir dëst?
LINUX wéi mir wëssen ass e Kernel an net e Betribssystem, verschéckt mat verschiddene Verdeelungen wéi: Debian, Fedora, Ubuntu etc. a vill méi. Ubuntu OS entwéckelt vum Mark Shuttleworth ass populär bekannt a vill vu ville benotzt. Och ass gratis an Open Source seng nei Versioun jäerlech verëffentlecht déi vun Dausende vun Entwéckler bäigedroen gëtt, déi zu senger Entwécklung bäidroen. Awer, wéi funktionéiert et? Wat all Prozesser, Lëscht vun Eventer maachen et ze schaffen a wat ass d'Bedeitung vun dëse Prozesser?
Dësen Artikel wäert Iech e bëssen déif an d'Innere vum Ubuntu OS huelen, déi ganz interessant sinn an engem Ufänger hëllefen e komplette Verständnis vu sengem Fonctionnement ze hunn.
Lay Down vum System
Linux huet e Prozess fir säi Fonctionnement, all Systemservice inklusiv Stroumverwaltung, Bootup, System Crash Handhabung ass e Prozess deen eng Konfiguratiounsdatei an \/etc/init huet, déi den Event op beschreift déi et ausféiert an entspriechend Event op deem et seng Ausféierung géif stoppen, zesumme mat deem et och seng aner Konfiguratiounsdateien ënnerhält, déi säi Run-Time Verhalen am System \/etc/ Verzeechnes beschreiwen, also mécht de System en Event gedriwwen.
Wann et Eventer generéiert ginn, da soll een do sinn fir se ze fänken an se auszeféieren?? Gutt offensichtlech ass de Controller eisen Haaptprozess deen als Elterendeel vun all Prozesser mat Prozess ID 1 dh init existéiert. Dëst ass de Prozess dee mam Start vum System ufänkt an ni ophält. Dëse Prozess stierft nëmmen eemol de System ugedriwwe gëtt well et kee Prozess ass deen den Elterendeel vun der Init ass.
Fréier Versioune vu Ubuntu virun 6.10 enthalen alen Stil sysvinit dee benotzt gouf fir Scripten an \/etc/rcx.d< ze lafen Verzeechnes bei all Startup a Shutdown vum System. Awer no deem upstart System huet den alen Stil sysvinit System ersat, awer stellt ëmmer nach Réckkompatibilitéit fir et.
Déi lescht Ubuntu Versiounen hunn dësen Upstart System, awer zënter senger Evolutioun vu Ubuntu 6.10 ass et e puer Versioune ginn, déi aktuell Versioun ass 1.13.2 wéi de 4. September 2014. De leschten Upstart System huet 2 Init Prozesser, een fir de Systemprozesser an en aneren deen déi aktuell ugemellte Benotzersession geréiert an existéiert nëmme bis de Benotzer ageloggt ass, och genannt x-Session init .
De ganze System ass als hierarchesch festgeluecht ginn, besteet aus Virfahre-Kand Relatioun uechter d'Kraaft bis zum Kraaft vum System.
Zum Beispill: Eng kleng hierarchesch Relatioun tëscht béiden Init Prozesser ass: System init(1) -> Displaymanager (Kernelraum) -> Displaymanager (Benotzerraum) -> Benotzer init(oder x- Sëtzung init).
D'Konfiguratiounsdateien fir Prozesser, déi vum System init geréiert sinn, wunnen am \/etc/init a fir déi, déi duerch Sessioun init geréiert ginn, wunnen an \/usr/share/upstart (wéi pro aktuell Upstart Versiounen uewen 1.12) an dës Konfiguratiounsdateien si Schlëssel fir vill opgedeckte Geheimnisser iwwer Prozesser wéi an dësem Artikel beschriwwen.
Gitt méi Déif an d'Hierarchie
Ubuntu erkennt zwou Aarte vu Prozesser:
- Kuerz gelieft Aarbechtsplazen (oder Aarbecht-a-stierwen Aarbechtsplazen).
- Laang gelieft Aarbechtsplazen (oder Stay-and-work Jobs).
D'Hierarchie déi um System gemaach gëtt ass wéinst der Ofhängegkeetsbezéiung tëscht Prozesser déi mir kënne verstoen andeems se hir Konfiguratiounsdateien kucken. Loosst eis fir d'éischt vun enger einfacher hierarchescher Bezéiung tëscht de Prozesser ufänken, déi de System booten an d'Bedeitung vun all eenzel vun hinnen verstoen.
Init ass deen éischte Prozess dee mam Stroum un de System ufänkt an ass ënner Work-and-stay Job klasséiert well et ni ëmbruecht gëtt an déi eenzeg Kéier datt den Init ëmbruecht gëtt ass op auszeschalten dh init stierft nëmmen an dat och eemol pro Sessioun an dat ass um ausschalten. Beim Opstart generéiert init dat éischt Event um System dh Startup Event. All Configuratiounsdatei an \/etc/init huet zwou Zeilen, déi den Event definéieren, deen de Prozess ufänkt an ophält.
Dëst ass eng Konfiguratiounsdatei vun engem Prozess failsafe-x an dës fänken un a stoppen op Konditioune beschreiwen den Event op deem de Prozess ufänkt. Beim Generatioun vum Startup Event duerch Init Prozess ginn déi Prozesser déi Startup als Start op Conditioun hunn parallel ausgefouert an dëst definéiert nëmmen d'Hierarchie, an all Prozesser déi beim Startup ausféieren sinn Kanner vun Init.
D'Prozesser, déi beim Start starten, ginn als ënner opgelëscht an dëst sinn all Aarbecht-a-stierwen Aarbechtsplazen:
1. Hostnumm - Dëst ass e Prozess dee just de System vu sengem Hostnumm erzielt deen an /etc/hostname Datei definéiert ass.
2. kmod - Luet d'Kernelmodule dh all Treiber aus /etc/modules Datei.
3. mountall - Dëse Prozess generéiert vill Eventer an ass haaptsächlech verantwortlech fir all d'Dateisystemer beim Boot ze montéieren inklusiv lokal Dateiesystemer a Ferndateiesystemer.
D'/proc-Datei gëtt och duerch dëse Prozess montéiert an no all Montageaarbecht ass dee leschten Event, deen dovunner generéiert gëtt, Dateisystemevent, wat d'Hierarchie weider mécht.
4. Plymouth - Dëse Prozess leeft beim Start vum Mountall aus an ass verantwortlech fir dee schwaarzen Ecran ze weisen deen um Systemstartup gesi gëtt, deen eppes weist wéi hei drënner:
5. Plymouth-prett - Gëtt un datt de Plymouth erop ass.
Folgend sinn Haaptprozess, aner déi och beim Startup ausféieren enthalen, wéi udev-fallback-Grafiken, etc.. Zréck op d'Boothierarchie kommen, an enger Nossschuel sinn d'Evenementer a Prozesser déi folgend sinn wéi an der Sequenz:
1. init zesumme mat der Generatioun vum Startup Event.
2. Mountall Montéierung Dateiesystemer, Plymouth (zesumme mam Start Mount) déi de Splashscreen affichéiert, a kmod Luede Kernel Moduler.
3. Lokal Dateiesystem Event generéiert vum Mountall, deen d'Dbus leeft. (Dbus ass de System breet Message Bus deen e Socket erstellt fir aner Prozesser mateneen ze kommunizéieren iwwer Messagen op dës Socket ze schécken an den Empfänger lauschtert no de Messagen op dësem Socket a filtert déi fir se geduecht).
4. Lokal Dateiesystem zesumme mat ugefaange dbus a statesche Netzwierk-up Event verursaacht vum Prozessnetz, deen och op lokalen Dateiesystem Event leeft, verursaacht den Netzmanager lafen.
5. virtuell Dateiesystem Event generéiert vum Mountall verursaacht udev fir ze lafen. (udev ass den Apparat Manager fir Linux deen d'Hot-Plugging vun Apparater geréiert an ass verantwortlech fir Dateien am /dev Verzeichnis ze kreéieren an se och ze managen.) udev erstellt Dateien fir Ram, Rom etc an /dev Verzeechnes déi de Mount huet fäerdeg virtuell montéiert -filesystems an huet d'Evenement virtuell-Dateiesystem generéiert wat d'Montage vum /dev Verzeechnes bedeit.
6. udev bewierkt datt Upstart-udev-Bréck leeft, wat bedeit datt de lokalen Netzwierk op ass. Dann nodeems de Mountall de leschte Dateiesystem montéiert huet an de Dateisystem Event generéiert huet.
7. Dateiesystem Event zesumme mat static-network-up Event verursaacht rc-sysinit Job fir ze lafen. Hei kënnt d'Réckkompatibilitéit tëscht eelere Sysvinit an Upstart ...
9. rc-sysinit leeft den telinit Kommando deen de System Runlevel seet.
10. Nodeems Dir de Runlevel kritt hutt, féiert den Init d'Skripte aus, déi mat 'S' oder 'K' ufänken (Startplazen ufänken déi 'S' am Ufank vun hirem Numm hunn an déi ëmbréngen déi 'K' am Ufank vun hirem Numm hunn) am Verzeechnes/etc/rcX.d (wou 'X' den aktuelle Runlevel ass).
Dëse klenge Set vun Eventer veruersaacht datt de System all Kéier starten wann Dir et uschalt. An, dëst Event Ausléiser vu Prozesser ass dat eenzegt wat verantwortlech ass fir d'Hierarchie ze kreéieren.
Elo, en aneren Add-on uewen ass d'Ursaach vum Event. Wéi ee Prozess verursaacht wéi en Event ass och an därselwechter Konfiguratiounsdatei vum Prozess spezifizéiert wéi hei ënnendrënner an dëse Linnen:
Uewen ass eng Sektioun vun der Konfiguratiounsdatei vum Prozess mountall. Dëst weist d'Evenementer déi et emittéiert. Den Numm vum Event ass een nom Wuert 'Evenement'. Event kann entweder deen an der Konfiguratiounsdatei definéiert sinn wéi hei uewen oder kann den Numm vum Prozess sinn zesumme mam Präfix 'ugefaangen', 'ugefaangen', 'stoppen' oder 'gestoppt'.
Also, Hei definéiere mir zwee Begrëffer:
- Event Generator: Een deen d'Linn 'emits xxx' a senger Konfiguratiounsdatei huet, wou xxx den Numm vum Event ass deen et besëtzt oder generéiert.
- Evenement Catcher: Een deen säin Start op oder Stop Conditioun als xxx huet oder deen ufänkt oder stoppt um Event generéiert ee vun den Event Generatoren.
Also folgt d'Hierarchie an sou d'Ofhängegkeet tëscht Prozesser:
Event generator (parent) -> Event catcher (child)
Bis elo musst Dir verstanen hunn wéi d'Hierarchie vun der Elteren-Kand Ofhängegkeet tëscht de Prozesser duerch de Event Ausléiser Mechanismus duerch en einfachen Boot-Up Mechanismus festgeluecht gëtt.
Elo, dës Hierarchie ass ni eng een-zu-een Relatioun mat nëmmen een Elterendeel fir ee Kand. An dëser Hierarchie hu mir vläicht een oder méi Elteren fir ee Kand oder ee Prozess als Elterendeel vu méi wéi engem Kand. Wéi gëtt dat realiséiert?? Gutt, d'Äntwert läit an de Konfiguratiounsdateien selwer.
Dës Linnen sinn aus Prozess geholl - Vernetzung an hei den Ufank op Conditioun schéngt e bëssen ze komplex aus villen Eventer ze komponéieren nämlech - lokal-Dateiesystemer, udevtrigger, Container, runlevel, Networking.
Lokal-Dateiesystemer gëtt vum mountall emittéiert, udevtrigger ass den Numm vun der Aarbecht, Container-Event gëtt vum Container-Detect emittéiert, Runlevel Event emittéiert vum rc-sysinit, an Netzwierker ass erëm eng Aarbecht.
Also, an enger Hierarchie ass de Prozessvernetzung Kand vum Mountall, udevtrigger a Container-entdecken well et net weider funktionnéiert (Funktionéiere vum Prozess ass all d'Linnen déi ënner Skript oder Exec Sektiounen an der Konfiguratiounsdatei vum Prozess definéiert sinn) bis déi uewe genannte Prozesser hir Eventer generéieren.
Och kënne mir ee Prozess hunn als Elterendeel vu ville wann d'Evenement generéiert vun engem Prozess vu villen cache gëtt.
Wéi virdru definéiert, kënne mir entweder kuerz lieweg (oder Aarbecht-a-stierwen Aarbechtsplazen) oder laang lieweg (oder bleiwen-an-Aarbecht) Aarbechtsplazen hunn, awer wéi z'ënnerscheeden tëscht hinnen??
D'Aarbechten déi souwuel 'Start on' wéi och 'Stop on' Bedéngungen an hire Konfiguratiounsdateien spezifizéiert hunn an e Wuert 'task' an hirer Konfiguratiounsdatei sinn work-and-die Aarbechtsplazen déi um generéierten Event starten, hiren Skript oder Exec Sektioun ausféieren (während se ausféieren, blockéiere se d'Evenementer déi se verursaacht hunn) a stierwen duerno déi Eventer fräiginn déi se blockéiert hunn .
Déi Aarbechtsplazen déi net an hirer Konfiguratiounsdatei 'stopp op' Zoustand hunn, si laang gelieft oder bleif-an-schaffen Aarbechten a si stierwen ni. Elo kënnen d'Openthalt-an-Aarbecht Aarbechtsplaze weider klasséiert ginn:
- Déi, déi kee respawn Zoustand hunn a kënnen duerch de Root Benotzer ëmbruecht ginn.
- Déi, déi de Conditioun an hirer Konfiguratiounsdatei nei erstallt hunn a sou datt se nei starten nodeems se ëmbruecht goufen, ausser hir Aarbecht ass ofgeschloss.
Conclusioun
Also ass all Prozess an LINUX ofhängeg vun e puer an huet e puer Prozesser ofhängeg vun deem an dës Bezéiung ass vill op vill a gëtt mam Upstart System zesumme mat aneren Detailer vum Prozess spezifizéiert.