Weboldal keresés

Deep Insights of "Ubuntu Linux" System – látjuk ezt?


A LINUX, mint tudjuk, egy kernel, nem pedig operációs rendszer, számos disztribúcióval érkezik, például: Debian, Fedora, Ubuntu stb és még sok más. AMark Shuttleworth által fejlesztett Ubuntu operációs rendszert sokan ismerik és széles körben használják. Továbbá, mivel ingyenes és nyílt forráskódú, az új verziója évente jelenik meg, amelyhez több ezer fejlesztő hozzájárult, akik hozzájárulnak a fejlesztéséhez. De hogyan működik? Milyen folyamatok, események listája teszi működőképessé, és mi ezeknek a folyamatoknak a jelentősége?

Ez a cikk egy kicsit mélyebben elvezeti az Ubuntu OS belső részleteibe, amelyek nagyon érdekesek, és segítenek a kezdőknek abban, hogy teljes mértékben megértsék a működését.

Állítsa le a rendszert

A Linuxnak van egy folyamata a működéséhez, minden egyes rendszerszolgáltatás, beleértve az energiagazdálkodást, a rendszerindítást és a rendszerösszeomlás kezelését, egy olyan folyamat, amelynek az „/etc/init” könyvtárban van egy konfigurációs fájlja, amely leírja az eseményt, amelyen végrehajtja a megfelelő eseményt, amelyen leállítja a végrehajtást, valamint fenntartja a többi konfigurációs fájlját is, amelyek leírják a futási viselkedését a rendszer “/etc/ ” könyvtárában, így a rendszer eseményvezérelt.

Ha vannak események generálva, akkor valakinek ott kell lennie, hogy elkapja és végrehajtsa őket? Nyilvánvaló, hogy a vezérlő a fő folyamatunk, amely minden 1 folyamatazonosítójú folyamat szülőjeként létezik, azaz init. Ez az a folyamat, amely a rendszer indításával kezdődik, és soha nem áll le. Ez a folyamat csak a rendszer kikapcsolása után hal meg, mivel nincs olyan folyamat, aki az init szülője.

Az Ubuntu korábbi, 6.10 előtti verziói tartalmazták a régi stílusú sysvinit-et, amelyet a szkriptek futtatására használtak a „/etc/rcx.dben b> ” könyvtárat a rendszer minden indításakor és leállításakor. Ám ezt követően az upstart rendszer felváltotta a régi stílusú sysvinit rendszert, de még mindig visszamenőleges kompatibilitást biztosít vele.

A legújabb Ubuntu-verziók rendelkeznek ezzel a feltörekvő rendszerrel, de az Ubuntu 6.10-ből történő kifejlesztése óta számos felülvizsgálaton esett át a jelenlegi verzió: 1.13.2, 2014. szeptember 4-én. 2 init folyamattal rendelkezik, az egyik a rendszerfolyamatokhoz, a másik pedig az aktuális bejelentkezett felhasználói munkamenetet kezeli, és csak addig létezik, amíg a felhasználó be nem jelentkezik, más néven x-session init .

Az egész rendszert hierarchikus rendszerként fektették le, amely az ős-gyermek kapcsolatból áll a rendszer teljesítményétől egészen a lekapcsolásig.

Például: Egy kis hierarchikus kapcsolat a két init folyamat között a következő: system init(1) -> display manager(kernel space) -> megjelenítéskezelő(felhasználói terület) -> user init(vagy x-session init).

A rendszerinit által kezelt folyamatok konfigurációs fájljai a „/etc/init”, a session init által kezelt folyamatok konfigurációs fájljai pedig a „/usr/share/upstart” mappában találhatók (mint a jelenlegi, 1.12 feletti verzióknak megfelelően, és ezek a konfigurációs fájlok kulcsfontosságúak a folyamatokkal kapcsolatos számos, ebben a cikkben leírt titokhoz.

Mélyebbre jutás a hierarchiában

Az Ubuntu kétféle folyamatot ismer fel:

  1. Rövid ideig tartó állások (vagy munka-halál állások).
  2. Hosszú életű munkák (vagy maradás és munka).

A rendszeren létrejövő hierarchia a folyamatok közötti függőségi kapcsolatnak köszönhető, amelyet a konfigurációs fájljaik megtekintésével érthetünk meg. Kezdjük először egy egyszerű hierarchikus kapcsolatból a rendszert indító folyamatok között, és értsük meg mindegyik jelentőségét.

Rendszerindítási hierarchia

Az Init az első folyamat, amely elindul a rendszer bekapcsolásakor, és a munka és maradás munkakörbe tartozik, mivel soha nem kerül leállításra, és csak az init leállítása van bekapcsolva. kikapcsolás, azaz az init csak meghal, és az is munkamenetenként egyszer, az pedig a kikapcsoláskor. Bekapcsoláskor az init generálja a legelső eseményt a rendszeren, azaz az indítási eseményt. Az „/etc/init” minden konfigurációs fájlja két sorral rendelkezik, amelyek meghatározzák azt az eseményt, amely a folyamat indítását és leállítását okozza. Ezek a sorok az alábbi ábrán láthatók:

Ez a failsafe-x folyamat konfigurációs fájlja, és ezek olyan feltételekkel indulnak és állnak le, amelyek leírják azt az eseményt, amelyen a folyamat elindul. Az indítási esemény init folyamatonkénti generálásakor azok a folyamatok párhuzamosan futnak le, amelyeknek a feltételes indítása az indítás, és ez csak a hierarchiát határozza meg, és az indításkor végrehajtott összes folyamat az init gyermeke.

Az indításkor induló folyamatok az alábbiak szerint vannak felsorolva, és ezek mind „work-and-die” feladatok:

1. gazdanév – Ez egy olyan folyamat, amely csak közli a rendszerrel az /etc/hostname fájlban megadott gazdagépnevét.

2. kmod – Betölti a kernelmodulokat, azaz az összes illesztőprogramot az /etc/modules fájlból.

3. mountall – Ez a folyamat sok eseményt generál, és főként az összes fájlrendszer összeillesztéséért felelős a rendszerindításkor, beleértve a helyi fájlrendszereket és a távoli fájlrendszereket is.

A /proc fájlt is ez a folyamat csatolja be, és a beillesztési munka után az általa generált utolsó esemény a fájlrendszer eseménye, amely tovább viszi a hierarchiát.

4. plymouth – Ez a folyamat a mountall indításakor megy végbe, és felelős azért, hogy megjelenjen a rendszer indításakor látható fekete képernyő, és valami az alábbiakat mutatja:

5. plymouth-ready – Azt jelzi, hogy a plymouth felállt.

Az alábbiakban a fő folyamatok láthatók, az indításkor végrehajtott egyéb folyamatok közé tartozik például az udev-fallback-graphics stb. Visszatérve a rendszerindítási hierarchiához, dióhéjban a következő események és folyamatok egymás után következnek:

1. init az indítási esemény generálásával együtt.

2. mountall csatoló fájlrendszerek, plymouth (az indító mountall-lal együtt), amely megjeleníti a kezdőképernyőt, és a kmod betölti a kernelmodulokat.

3. A mountall által generált local-filesystem esemény a dbus futtatását okozza. (A Dbus a rendszerszintű üzenetbusz, amely egy socketet hoz létre, amely lehetővé teszi, hogy más folyamatok kommunikáljanak egymással az erre a socketre küldött üzeneteken keresztül, és a vevő figyeli az ezen a socketen lévő üzeneteket és szűri a neki szánt üzeneteket).

4. A local-filesystem a folyamathálózat által okozott elindított dbus és static-network-up esemény, amely szintén a helyi fájlrendszer eseményén fut, a network-manager futását idézi elő.

5. A mountall által generált virtual-filesystem esemény hatására az udev fut. (Az udev a linux eszközkezelője, amely kezeli az eszközök üzem közbeni csatlakoztatását, és felelős a fájlok létrehozásáért a /dev könyvtárban és ezek kezeléséért is.) Az udev a ram, rom stb. fájlokat hoz létre a /dev könyvtárban, ahol a mountall befejezte a virtuális csatlakoztatást -filesystems, és létrehozta a virtuális fájlrendszer eseményt, amely a /dev könyvtár csatlakoztatását jelzi.

6. Az udev hatására az upstart-udev-bridge fut, ami azt jelzi, hogy a helyi hálózat működik. Majd miután a mountall befejezte az utolsó fájlrendszer csatlakoztatását, és létrehozta a fájlrendszer eseményét.

7. A fájlrendszer esemény és a static-network-up esemény az rc-sysinit feladat futtatását okozza. Itt jön a visszamenőleges kompatibilitás a régebbi sysvinit és az upstart között…

9. Az rc-sysinit a telinit parancsot futtatja, amely tájékoztatja a rendszer futási szintjét.

10. A futási szint megszerzése után az init végrehajtja azokat a szkripteket, amelyek "S" vagy "K" betűkkel kezdődnek (olyan jobok elindítása, amelyekben "S" van a nevük eleje, és megöli azokat, akiknek a nevük elején „K” szerepel) az /etc/rcX.d könyvtárban (ahol az „X” az aktuális futási szint) .

Ez a kis eseményhalmaz a rendszert minden egyes bekapcsoláskor elindítja. És ez a folyamatok eseményindítója az egyetlen, ami felelős a hierarchia kialakításáért.

Most egy másik kiegészítő a fentihez az esemény oka. Az, hogy melyik folyamat melyik eseményt okozza, a folyamatnak ugyanabban a konfigurációs fájljában is meg van határozva, ahogy az alábbi sorokban látható:

Fent a process mountall konfigurációs fájljának egy része látható. Ez mutatja az általa kibocsátott eseményeket. Az esemény neve az „esemény” szót követi. Az esemény lehet a konfigurációs fájlban a fentiek szerint definiált, vagy lehet a folyamat neve a 'start' , 'indult', 'stop' vagy 'stop' előtaggal együtt.

Tehát itt két fogalmat határozunk meg:

  1. Eseménygenerátor: Olyan, amelynek konfigurációs fájljában az „emits xxx” sor szerepel, ahol az xxx a tulajdonában lévő vagy generált esemény neve.
  2. Eseményfogó: Olyan, amelynek kezdési vagy leállítási feltétele xxx, vagy amely az egyik eseménygenerátort generált eseményen kezdődik vagy leáll.

Így a hierarchia következik, és így a folyamatok közötti függőség:

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

Bonyolultság hozzáadása a hierarchiához

Eddig bizonyára megértette, hogy a folyamatok közötti szülő-gyermek függőségi hierarchiát az eseményindító mechanizmus határozza meg egy egyszerű rendszerindítási mechanizmuson keresztül.

Nos, ez a hierarchia soha nem egy-egy kapcsolat, amelynek egyetlen szülője csak egy gyermekhez tartozik. Ebben a hierarchiában előfordulhat, hogy egy gyermekhez egy vagy több szülő tartozik, vagy egy folyamat több gyermek szülője lehet. Ez hogy valósul meg?? Nos, a válasz magában a konfigurációs fájlokban rejlik.

Ezek a sorok a folyamatból – hálózatépítésből származnak, és itt a feltételes indítás túl bonyolultnak tűnik, és sok eseményből áll, nevezetesen – helyi fájlrendszerek, udevtrigger, container, futási szint, hálózati.

A helyi fájlrendszereket a mountall bocsátja ki, az udevtrigger a feladat neve, a konténereseményt a container-detect, a futási szintű eseményt az rc-sysinit, és a hálózatépítés ismét egy job.

Így egy hierarchiában a folyamathálózat a mountall, az udevtrigger és a container-detect gyermeke, mivel nem tudja folytatni működését (a folyamat működése a folyamat konfigurációs fájljában a script vagy exec szakaszok alatt definiált összes sor) amíg a fenti folyamatok nem generálják eseményeiket.
Hasonlóképpen lehet, hogy egy folyamat több szülője lehet, ha az egy folyamat által generált eseményt többen gyorsítótárazzák.

Munkakörtípusok megkülönböztetése

A korábban meghatározottak szerint lehetnek rövid életű (vagy dolgozz és halj) vagy hosszú életű (vagy maradj és dolgozz) munkáink, de hogyan lehet megkülönböztetni őket??

Azok a jobok, amelyek konfigurációs fájljaiban a 'start on' és 'stop on' feltételek is meg vannak határozva, és a nevükben szerepel a 'task' szó. A konfigurációs fájlok work-and-die jobok, amelyek a generált eseményen indulnak el, végrehajtják a script vagy exec szakaszt (végrehajtás közben blokkolják az azokat okozó eseményeket), majd elhalnak, felszabadítva azokat az eseményeket, amelyeket blokkoltak. .

Azok a munkák, amelyek konfigurációs fájljában nincs „stop on” feltétel, hosszú életű vagy maradj és dolgozz munkák, és soha nem halnak meg. Mostantól a maradási és munkahelyi munkák a következőképpen osztályozhatók:

  1. Azok, amelyeknek nincs respawn feltétele, és a root felhasználó megölheti őket.
  2. Azok, amelyeknek a konfigurációs fájljában respawn feltétel van, ezért újraindulnak, miután megölték, hacsak a munkájuk nem fejeződött be.

Következtetés

Így a LINUX minden egyes folyamata függ néhánytól, és vannak tőlük függő folyamatok, és ez a kapcsolat sok mástól függ, és az induló rendszerrel van megadva a folyamat egyéb részleteivel együtt.