Coneixements profunds del sistema Ubuntu Linux: ho veiem?

LINUX, com sabem, és un nucli i no un sistema operatiu, s'envia amb diverses distribucions com: Debian, Fedora, Ubuntu, etc. i moltes més. El sistema operatiu Ubuntu desenvolupat per Mark Shuttleworth és conegut popularment i molt utilitzat per molts. A més, al ser gratuïta i de codi obert es publica anualment la seva nova versió a la qual aporten milers de desenvolupadors que contribueixen al seu desenvolupament. Però, com funciona? Quins són tots els processos, la llista d'esdeveniments que fan que funcioni i quina és la importància d'aquests processos?

Aquest article us aprofundirà una mica en els aspectes interns del SO d'Ubuntu que són molt interessants i ajudaria a un principiant a entendre'n completament el funcionament.

Establiment del sistema

Linux té un procés per al seu funcionament, tots i cadascun dels serveis del sistema, inclosa la gestió de l'energia, l'arrencada, la gestió de fallades del sistema, és un procés que té un fitxer de configuració a \/etc/init que descriu l'esdeveniment a que executarà i l'esdeveniment corresponent en què aturaria la seva execució, juntament amb això també manté els seus altres fitxers de configuració que descriuen el seu comportament en temps d'execució al directori \/etc/ del sistema, per tant fent del sistema un esdeveniment impulsat.

Si es generen esdeveniments, algú hauria d'estar allà per capturar-los i executar-los? Òbviament, el controlador és el nostre procés principal que existeix com a pare de tots els processos amb l'identificador de procés 1, és a dir, init. Aquest és el procés que comença amb l'inici del sistema i no s'atura mai. Aquest procés només s'apaga un cop s'apaga el sistema, ja que no hi ha cap procés que sigui el pare d'init.

Les versions anteriors d'Ubuntu anteriors a 6.10 incloïen sysvinit d'estil antic que s'utilitzava per executar scripts a \/etc/rcx.d” a cada inici i tancament del sistema. Però, després d'aquest, el sistema upstart va substituir el sistema sysvinit d'estil antic, però encara li proporciona compatibilitat enrere.

Les últimes versions d'Ubuntu tenen aquest sistema advengut, però des de la seva evolució a partir d'Ubuntu 6.10 s'ha fet diverses revisions, la versió actual, sent la 1.13.2 del 4 de setembre de 2014. L'últim sistema d'inici. té 2 processos init, un per als processos del sistema i un altre que gestiona la sessió actual d'usuari connectat i només existeix fins que l'usuari ha iniciat sessió, també anomenat x-session init .

Tot el sistema s'ha establert com un de jeràrquic, que consisteix en la relació ancestre-fill al llarg de l'alimentació fins a l'apagada del sistema.

Per exemple: una petita relació jeràrquica entre els dos processos d'inici és: system init(1) -> display manager (kernel space) -> display manager (user space) -> user init (o x- sessió iniciada).

Els fitxers de configuració per als processos gestionats pel sistema init resideixen a \/etc/init i per als gestionats per session init resideixen a \/usr/share/upstart (segons les versions inicials actuals anteriors a 1.12) i aquests fitxers de configuració són clau per a molts secrets descoberts sobre processos tal com es descriu en aquest article.

Aprofundir més en la jerarquia

Ubuntu reconeix dos tipus de processos:

Ocupacions de curta durada (o feines de treball i mort).
Ocupacions de llarga vida (o feines de permanència).

La jerarquia que es fa al sistema es deu a la relació de dependència entre processos que podem entendre visualitzant els seus fitxers de configuració. Comencem primer d'una simple relació jeràrquica entre els processos que fan que el sistema arrenqui i entengui la importància de cadascun d'ells.

Init és el primer procés que s'inicia en encendre el sistema i es classifica a la feina treballar i quedar, ja que no s'atura mai i només s'activa el moment en què s'encén l'inici. apagant, és a dir, init només mor i això també una vegada per sessió i que s'apaga. En engegar, init genera el primer esdeveniment del sistema, és a dir, l'esdeveniment d'inici. Cada fitxer de configuració a \/etc/init té dues línies que defineixen l'esdeveniment que fa que el procés s'iniciï i s'aturi. Aquestes línies es destaquen a la figura següent:

Aquest és un fitxer de configuració d'un procés failsafe-x i aquests s'inicien i s'aturen quan les condicions descriuen l'esdeveniment en què s'iniciarà el procés. En generar un esdeveniment d'inici per procés d'inici, aquells processos que tenen l'inici com a condició d'inici s'executen en paral·lel i això només defineix la jerarquia, i tots els processos que s'executen a l'inici són fills d'init.

Els processos que s'inicien a l'inici s'enumeren a continuació i aquests són tots els treballs de treball i mort:

1. hostname: aquest és un procés que només indica al sistema el seu nom d'amfitrió definit al fitxer /etc/hostname.

2. kmod: carrega els mòduls del nucli, és a dir, tots els controladors del fitxer /etc/modules.

3. mountall: aquest procés genera molts esdeveniments i és principalment responsable de muntar tots els sistemes de fitxers a l'arrencada, inclosos els sistemes de fitxers locals i els sistemes de fitxers remots.

El fitxer /proc també es munta mitjançant aquest mateix procés i després de tot el treball de muntatge, l'últim esdeveniment generat per ell és l'esdeveniment del sistema de fitxers que fa que la jerarquia continuï més endavant.

4. plymouth: aquest procés s'executa en iniciar mountall i s'encarrega de mostrar la pantalla negra que es veu a l'inici del sistema que mostra alguna cosa com a continuació:

5. plymouth-ready: indica que el plymouth està a punt.

A continuació es mostren els processos principals, altres que també s'executen a l'inici, com ara udev-fallback-graphics, etc. Tornant a la jerarquia d'arrencada, en poques paraules, els esdeveniments i processos que segueixen són els següents:

1. init juntament amb la generació de l'esdeveniment d'inici.

2. mountall muntant sistemes de fitxers, plymouth (juntament amb l'inici de mountall) mostrant la pantalla de presentació i kmod carregant mòduls del nucli.

3. Esdeveniment del sistema de fitxers local generat per mountall que fa que s'executi dbus. (Dbus és el bus de missatges a tot el sistema que crea un sòcol que permet que altres processos es comuniquin entre ells mitjançant l'enviament de missatges a aquest sòcol i el receptor escolta els missatges d'aquest sòcol i filtra els destinats a ell).

4. El sistema de fitxers local juntament amb l'esdeveniment dbus iniciat i de xarxa estàtica causat per la xarxa de procés que també s'executa en l'esdeveniment del sistema de fitxers local fa que el gestor de xarxa s'executi.

5. L'esdeveniment sistema de fitxers virtual generat per mountall fa que l'udev s'executi. (udev és el gestor de dispositius per a Linux que gestiona la connexió en calent dels dispositius i s'encarrega de crear fitxers al directori /dev i gestionar-los també.) udev crea fitxers per a ram, rom, etc. al directori /dev, els que mountall ha acabat de muntar virtuals -filesystems i ha generat l'esdeveniment virtual-filesystem que significa muntatge del directori /dev.

6. udev fa que s'executi upstart-udev-bridge que significa que la xarxa local està activada. Aleshores, després que mountall hagi acabat de muntar l'últim sistema de fitxers i hagi generat l'esdeveniment del sistema de fitxers.

7. L'esdeveniment sistema de fitxers juntament amb l'esdeveniment static-network-up fa que s'executi el treball rc-sysinit. Aquí ve la compatibilitat enrere entre el sysvinit més antic i el principiant...

9. rc-sysinit executa l'ordre telinit que indica el nivell d'execució del sistema.

10. Després d'obtenir el nivell d'execució, l'inici executa els scripts que comencen amb 'S' o 'K' (iniciant treballs que tenen 'S' al començament del seu nom i matant els que tenen 'K' al començament del seu nom) al directori/etc/rcX.d (on 'X' és el nivell d'execució actual).

Aquest petit conjunt d'esdeveniments fa que el sistema s'iniciï cada vegada que l'enceneu. I, aquest esdeveniment que desencadena processos és l'únic responsable de crear la jerarquia.

Ara, un altre complement a dalt és la causa de l'esdeveniment. Quin procés provoca quin esdeveniment també s'especifica en el mateix fitxer de configuració del procés, tal com es mostra a continuació en aquestes línies:

A dalt hi ha una secció del fitxer de configuració del procés mountall. Això mostra els esdeveniments que emet. El nom de l'esdeveniment és un que succeeix a la paraula esdeveniment. L'esdeveniment pot ser el definit al fitxer de configuració com a anterior o pot ser el nom del procés juntament amb el prefix iniciant, iniciat, aturat o aturat.

Així doncs, aquí definim dos termes:

Generador d'esdeveniments: un que té la línia emet xxx al fitxer de configuració, on xxx és el nom de l'esdeveniment que té o genera.
Event Catcher: un que té la condició d'inici o aturada com a xxx o que s'inicia o s'atura a l'esdeveniment generat un dels generadors d'esdeveniments.

Així, la jerarquia segueix i per tant la dependència entre processos:

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

Fins ara, heu d'haver entès com la jerarquia de la dependència parent-fill entre els processos s'estableix mitjançant el mecanisme d'activació d'esdeveniments mitjançant un mecanisme d'arrencada senzill.

Ara, aquesta jerarquia mai és una relació un a un amb només un pare per a un fill. En aquesta jerarquia podem tenir un o més pares per a un fill o un processa ser pare de més d'un fill. Com s'aconsegueix això?? Bé, la resposta es troba en els mateixos fitxers de configuració.

Aquestes línies s'extreuen del procés: la xarxa i aquí l'inici amb condició sembla una mica massa complex compost per molts esdeveniments, a saber: sistema de fitxers local, udevtrigger, contenidor, nivell d'execució, xarxes.

Els sistemes de fitxers locals són emesos per mountall, udevtrigger és el nom de la feina, l'esdeveniment de contenidor s'emet per container-detect, l'esdeveniment de nivell d'execució emès per rc-sysinit i la xarxa torna a ser una feina.

Així, en una jerarquia, la xarxa de processos és fill de mountall, udevtrigger i container-detect, ja que no pot continuar el seu funcionament (el funcionament del procés són totes les línies que es defineixen a les seccions script o exec al fitxer de configuració del procés). fins que els processos anteriors generen els seus esdeveniments.
De la mateixa manera, podem tenir un procés com a pare de molts si l'esdeveniment generat per un procés és guardat a la memòria cau per molts.

Tal com s'ha definit anteriorment, podem tenir feines de curta durada (o treballar i morir) o de llarga vida (o quedar-se i treballar), però com distingir entre ells??

Les feines que tenen les condicions inicia i stop on especificades als seus fitxers de configuració i tenen una paraula tasca al seu Els fitxers de configuració són treballs work-and-die que s'inicien a l'esdeveniment generat, executen el seu script o secció exec (mentre s'executen, bloquegen els esdeveniments que els van causar) i moren després alliberant aquells esdeveniments que van bloquejar. .

Aquelles feines que no tenen la condició stop on al fitxer de configuració són feines de llarga vida o queda i treballen i no moren mai. Ara els llocs de treball d'estada i treball es poden classificar més en:

Els que no tenen una condició de reaparició i poden ser matats per l'usuari root.
Els que han reaparegut en el seu fitxer de configuració i, per tant, es reinicien després de ser assassinats, tret que la seva feina s'hagi completat.

Conclusió

Per tant, cada procés a LINUX depèn d'alguns i en depenen alguns processos i aquesta relació és de molts i s'especifica amb el sistema inicial juntament amb altres detalls del procés.