Approfondimenti sul sistema "Ubuntu Linux": lo vediamo?

LINUX come sappiamo è un kernel e non un sistema operativo, viene fornito con diverse distribuzioni come: Debian, Fedora, Ubuntu ecc. e molti altri. Il sistema operativo Ubuntu sviluppato da Mark Shuttleworth è popolarmente conosciuto e ampiamente utilizzato da molti. Inoltre, essendo gratuito e Open Source, la sua nuova versione viene rilasciata ogni anno a cui contribuiscono migliaia di sviluppatori che contribuiscono al suo sviluppo. Ma come funziona? Quali sono tutti i processi, l'elenco degli eventi che lo fanno funzionare e qual è il significato di questi processi?

Questo articolo ti porterà un po' in profondità negli aspetti interni del sistema operativo Ubuntu che sono molto interessanti e aiuterebbero un principiante ad avere una comprensione completa del suo funzionamento.

Stabilizzazione del sistema

Linux ha un processo per il suo funzionamento, ogni servizio di sistema incluso la gestione dell'alimentazione, l'avvio, la gestione dei crash del sistema è un processo che ha un file di configurazione in "/etc/init" che descrive l'evento su cui si verifica eseguirà un evento corrispondente al quale interromperà la sua esecuzione, oltre a ciò mantiene anche gli altri file di configurazione che descrivono il suo comportamento in fase di esecuzione nella directory "/etc/" del sistema, rendendo così il sistema uno guidato dagli eventi.

Se vengono generati eventi, allora qualcuno dovrebbe essere lì per catturarli ed eseguirli?? Ovviamente, il controller è il nostro processo principale che esiste come genitore di tutti i processi con ID processo 1 cioè init. Questo è il processo che inizia con l'avvio del sistema e non si ferma mai. Questo processo muore solo una volta spento il sistema poiché non esiste alcun processo che sia il genitore di init.

Le versioni precedenti di Ubuntu prima della 6.10 includevano il vecchio stile sysvinit che veniva utilizzato per eseguire script in "/etc/rcx.d "directory ad ogni avvio e arresto del sistema. Ma, dopo quel sistema upstart ha sostituito il vecchio sistema sysvinit, ma fornisce comunque la compatibilità con le versioni precedenti.

Le ultime versioni di Ubuntu hanno questo sistema upstart, ma dalla sua evoluzione da Ubuntu 6.10 ha subito diverse revisioni. La versione attuale è 1.13.2 come il 4 settembre 2014. L'ultimo sistema upstart ha 2 processi init, uno per i processi di sistema e l'altro che gestisce la sessione corrente dell'utente connesso ed esiste solo finché l'utente non effettua l'accesso, chiamato anche x-session init .

L'intero sistema è stato strutturato in modo gerarchico, costituito dalla relazione antenato-figlio dall'accensione allo spegnimento del sistema.

Ad esempio: una piccola relazione gerarchica tra entrambi i processi init è: system init(1) -> display manager(spazio kernel) -> display manager (spazio utente) -> init utente (o x-session init).

I file di configurazione per i processi gestiti da system init risiedono in “/etc/init ” e per quelli gestiti da session init risiedono in “/usr/share/upstart” (come secondo le attuali versioni upstart sopra 1.12) e questi file di configurazione sono la chiave per molti segreti portati alla luce sui processi come descritto in questo articolo.

Approfondire di più la gerarchia

Ubuntu riconosce due tipi di processi:

1. Lavori di breve durata (o lavori "lavora e muori").
2. Lavori di lunga durata (o lavori di permanenza e lavoro).

La gerarchia creata nel sistema è dovuta alla relazione di dipendenza tra i processi che possiamo comprendere visualizzando i loro file di configurazione. Partiamo innanzitutto da una semplice relazione gerarchica tra i processi che fanno funzionare il sistema e comprendiamo il significato di ciascuno di essi.

Gerarchia di avvio

Init è il primo processo ad avviarsi all'accensione del sistema ed è classificato come lavoro work-and-stay poiché non viene mai interrotto e l'unica volta che l'init viene terminato è attivo spegnendosi, cioè init muore solo e anche quello una volta per sessione e questo avviene allo spegnimento. All'accensione, init genera il primo vero evento sul sistema, ovvero l'evento di avvio. Ogni file di configurazione in “/etc/init” ha due righe che definiscono l'evento che causa l'avvio e l'arresto del processo. Queste linee sono come evidenziate nella figura seguente:

Questo è un file di configurazione di un processo failsafe-x e queste condizioni di avvio e arresto on descrivono l'evento in cui verrà avviato il processo. Alla generazione dell'evento di avvio da parte del processo init, i processi che hanno startup come condizione di avvio vengono eseguiti in parallelo e questo definisce solo la gerarchia e tutti i processi eseguiti all'avvio sono figli di init.

I processi che iniziano all'avvio sono elencati di seguito e questi sono tutti lavori "lavora e muori":

1. hostname – Questo è un processo che comunica semplicemente al sistema il suo nome host definito nel file /etc/hostname.

2. kmod – Carica i moduli del kernel, ovvero tutti i driver dal file /etc/modules.

3. mountall – Questo processo genera molti eventi ed è principalmente responsabile del montaggio di tutti i filesystem all'avvio, inclusi i filesystem locali e quelli remoti.

Anche il file /proc viene montato proprio da questo processo e dopo tutto il lavoro di montaggio l'ultimo evento generato da esso è un evento del filesystem che fa procedere ulteriormente la gerarchia.

4. plymouth – Questo processo viene eseguito all'avvio di mountall ed è responsabile di mostrare la schermata nera visualizzata all'avvio del sistema che mostra qualcosa come di seguito:

5. Plymouth-ready – Indica che Plymouth è attivo.

Di seguito sono riportati i processi principali, altri che vengono eseguiti anche all'avvio, come udev-fallback-graphics, ecc. Tornando alla gerarchia di avvio, in poche parole gli eventi e i processi che seguono sono come in sequenza:

1. init insieme alla generazione dell'evento di avvio.

2. mountall monta i file system, plymouth (insieme all'avvio di mountall) mostra la schermata iniziale e kmod carica i moduli del kernel.

3. Evento local-filesystem generato da mountall che causa l'esecuzione di dbus. (Dbus è il bus di messaggi a livello di sistema che crea un socket consentendo ad altri processi di comunicare tra loro inviando messaggi a questo socket e il ricevitore ascolta i messaggi su questo socket e filtra quelli destinati ad esso).

4. local-filesystem insieme al dbus avviato e all'evento static-network-up causato dalla rete di processi che viene eseguita anche sull'evento local-filesystem provoca l'esecuzione del gestore di rete.

5. L'evento virtual-filesystem generato da mountall provoca l'esecuzione di udev. (udev è il gestore dispositivi per Linux che gestisce l'hot plug dei dispositivi ed è responsabile della creazione e della gestione dei file nella directory /dev.) udev crea file per ram, rom, ecc. nella directory /dev quando mountall ha terminato il montaggio virtuale -filesystems e ha generato l'evento virtual-filesystem che indica il montaggio della directory /dev.

6. udev fa eseguire upstart-udev-bridge, il che significa che la rete locale è attiva. Poi, dopo che mountall ha finito di montare l'ultimo filesystem e ha generato l'evento del filesystem.

7. L'evento filesystem insieme all'evento static-network-up provoca l'esecuzione del lavoro rc-sysinit. Qui arriva la compatibilità con le versioni precedenti tra il vecchio sysvinit e l'upstart...

9. rc-sysinit esegue il comando telinit che indica il runlevel del sistema.

10. Dopo aver ottenuto il runlevel, init esegue gli script che iniziano con 'S' o 'K' (avviando lavori che hanno 'S' in all'inizio del nome e uccidendo quelli che hanno 'K' all'inizio del nome) nella directory /etc/rcX.d (dove 'X' è il runlevel corrente) .

Questo piccolo insieme di eventi provoca l'avvio del sistema ogni volta che lo si accende. E questo evento che attiva i processi è l'unica cosa responsabile della creazione della gerarchia.

Ora, un'altra aggiunta a quanto sopra è la causa dell'evento. Quale processo causa quale evento è specificato anche nello stesso file di configurazione del processo come mostrato di seguito in queste righe:

Sopra c'è una sezione del file di configurazione del processo mountall. Questo mostra gli eventi che emette. Il nome dell'evento è quello che segue la parola "evento". L'evento può essere quello definito nel file di configurazione come sopra oppure può essere il nome del processo insieme al prefisso "starting", "started", "stopping" o "stopped".

Quindi, qui definiamo due termini:

1. Generatore di eventi: uno che ha la riga "emette xxx" nel suo file di configurazione dove xxx è il nome dell'evento che possiede o genera.
2. Event Catcher: uno che ha la sua condizione di avvio o arresto come xxx o che si avvia o si arresta in corrispondenza dell'evento generato da uno dei generatori di eventi.

Pertanto, segue la gerarchia e quindi la dipendenza tra i processi:

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

Aggiunta di complessità alla gerarchia

Fino ad ora, devi aver capito come la gerarchia della dipendenza genitore-figlio tra i processi è stabilita dal meccanismo di attivazione di eventi attraverso un semplice meccanismo di avvio.

Ora, questa gerarchia non è mai una relazione uno a uno con un solo genitore per un figlio. In questa gerarchia potremmo avere uno o più genitori per un figlio o un processo essere genitore di più di un figlio. Come si realizza ciò?? Ebbene la risposta sta nei file di configurazione stessi.

Queste righe sono prese da process – networking e qui la condizione start on sembra un po' troppo complessa composta da molti eventi vale a dire – local-filesystems, udevtrigger, container, runlevel, rete.

Local-filesystems viene emesso da mountall, udevtrigger è il nome del lavoro, l'evento contenitore viene emesso da container-detect, l'evento runlevel emesso da rc-sysinit e il networking è ancora una volta un lavoro.

Pertanto, in una gerarchia il processo di rete è figlio di mountall, udevtrigger e container-detect poiché non può continuare a funzionare (il funzionamento del processo è rappresentato da tutte le righe definite nelle sezioni script o exec nel file di configurazione del processo) finché i processi di cui sopra non generano i loro eventi.
Allo stesso modo, possiamo avere un processo genitore di molti se l'evento generato da un processo viene memorizzato nella cache da molti.

Distinguere i tipi di lavoro

Come definito in precedenza, possiamo avere lavori di breve durata (o lavori lavora e muori) o lavori di lunga durata (o rimani e lavora), ma come distinguere tra loro??

I lavori che hanno entrambe le condizioni 'avvia il' e 'arresta il' specificate nei loro file di configurazione e hanno una parola 'attività' nel loro file di configurazione sono lavori work-and-die che iniziano sull'evento generato, eseguono il loro script o la sezione exec (durante l'esecuzione bloccano gli eventi che li hanno causati) e muoiono successivamente rilasciando quegli eventi che avevano bloccato .

Quei lavori che non hanno la condizione "stop on" nel loro file di configurazione sono lavori di lunga durata o stay-and-work e non muoiono mai. Ora i lavori di soggiorno e lavoro possono essere ulteriormente classificati come:

1. Quelli che non hanno condizioni di respawn e possono essere uccisi dall'utente root.
2. Quelli che hanno una condizione di respawn nel loro file di configurazione e quindi riavviano dopo essere stati uccisi a meno che il loro lavoro non sia stato completato.

Conclusione

Pertanto, ogni processo in LINUX dipende da alcuni e ha alcuni processi che dipendono da esso e questa relazione è molti su molti ed è specificata con il sistema upstart insieme ad altri dettagli del processo.