Recherche de site Web

Aperçu approfondi du système « Ubuntu Linux » – Le voyons-nous ?

LINUX comme nous le savons est un noyau et non un système d'exploitation, livré avec plusieurs distributions comme : Debian, Fedora, Ubuntu etc. et bien d'autres. Le système d'exploitation Ubuntu développé par Mark Shuttleworth est populairement connu et largement utilisé par beaucoup. De plus, étant gratuite et Open Source, sa nouvelle version est publiée chaque année et bénéficie de la contribution de milliers de développeurs qui contribuent à son développement. Mais comment ça fonctionne ? Quels sont tous les processus, la liste des événements qui font que cela fonctionne et quelle est la signification de ces processus ?

Cet article vous plongera un peu plus profondément dans les composants internes du système d'exploitation Ubuntu qui sont très intéressants et aideraient un novice à avoir une compréhension complète de son fonctionnement.

Disposition du système

Linux a un processus pour son fonctionnement, chaque service système, y compris la gestion de l'alimentation, le démarrage et la gestion des pannes du système, est un processus qui possède un fichier de configuration dans « /etc/init » qui décrit l'événement sur lequel il exécutera et l'événement correspondant sur lequel il arrêterait son exécution, et il conservera également ses autres fichiers de configuration qui décrivent son comportement d'exécution dans le répertoire « /etc/ » du système, rendant ainsi le système une approche événementielle.

S'il y a des événements générés, alors quelqu'un devrait être là pour les attraper et les exécuter ?? Bien évidemment, le contrôleur est notre processus principal qui existe en tant que parent de tous les processus avec l'ID de processus 1, c'est-à-dire init. C'est le processus qui commence au démarrage du système et ne s'arrête jamais. Ce processus ne meurt qu'une fois le système mis hors tension, car aucun processus n'est le parent d'init.

Les versions antérieures de Ubuntu avant 6.10 incluaient l'ancien style sysvinit qui était utilisé pour exécuter des scripts dans « /etc/rcx.d »répertoire à chaque démarrage et arrêt du système. Mais, après cela, le système upstart a remplacé l'ancien système sysvinit, mais lui offre toujours une compatibilité ascendante.

Les dernières versions d'Ubuntu ont ce système de démarrage, mais depuis son évolution depuis Ubuntu 6.10, la version actuelle a subi plusieurs révisions étant 1.13.2 le 4 septembre 2014. Le dernier système de démarrage a 2 processus d'initialisation, un pour les processus système et un autre qui gère la session utilisateur actuellement connectée et n'existe que jusqu'à ce que l'utilisateur soit connecté, également appelé x-session init .

L'ensemble du système a été défini comme un système hiérarchique, consistant en une relation ancêtre-enfant tout au long de la mise sous tension jusqu'à la mise hors tension du système.

Par exemple : Une petite relation hiérarchique entre les deux processus d'initialisation est : system init(1) -> gestionnaire d'affichage (espace noyau) -> gestionnaire d'affichage (espace utilisateur) -> user init (ou x-session init).

Les fichiers de configuration des processus gérés par l'initialisation du système résident dans « /etc/init » et pour ceux gérés par l'initialisation de la session, résident dans « /usr/share/upstart » (comme selon les versions actuelles supérieures à 1.12) et ces fichiers de configuration sont la clé de nombreux secrets découverts sur les processus tels que décrits dans cet article.

Approfondir la hiérarchie

Ubuntu reconnaît deux types de processus :

  1. Emplois de courte durée (ou emplois de travail et de mort).
  2. Emplois de longue durée (ou emplois de séjour et de travail).

La hiérarchie établie sur le système est due à une relation de dépendance entre les processus que nous pouvons comprendre en visualisant leurs fichiers de configuration. Commençons par une simple relation hiérarchique entre les processus qui font démarrer le système et comprenons la signification de chacun d’eux.

Hiérarchie de démarrage

Init est le premier processus à démarrer à la mise sous tension du système et est classé sous la tâche travailler et rester car il n'est jamais tué et seul le moment où l'initialisation est interrompue est activé. la mise hors tension, c'est-à-dire que init ne meurt que et cela aussi une fois par session et c'est à la mise hors tension. A la mise sous tension, init génère le tout premier événement sur le système, c'est-à-dire l'événement de démarrage. Chaque fichier de configuration dans « /etc/init » comporte deux lignes qui définissent l'événement qui provoque le démarrage et l'arrêt du processus. Ces lignes sont telles que mises en évidence dans la figure ci-dessous :

Il s'agit d'un fichier de configuration d'un processus failsafe-x et ces conditions de démarrage et d'arrêt décrivent l'événement sur lequel le processus démarrera. Lors de la génération d'un événement de démarrage par le processus d'initialisation, les processus qui ont le démarrage comme condition de démarrage sont exécutés en parallèle et cela ne définit que la hiérarchie, et tous les processus qui s'exécutent au démarrage sont des enfants d'init.

Les processus qui démarrent au démarrage sont répertoriés ci-dessous et ce sont tous des emplois de travail et de mort :

1. nom d'hôte – Il s'agit d'un processus qui indique simplement au système son nom d'hôte défini dans le fichier /etc/hostname.

2. kmod – Charge les modules du noyau, c'est-à-dire tous les pilotes du fichier /etc/modules.

3. mountall – Ce processus génère de nombreux événements et est principalement responsable du montage de tous les systèmes de fichiers au démarrage, y compris les systèmes de fichiers locaux et les systèmes de fichiers distants.

Le fichier /proc est également monté par ce même processus et après tout le travail de montage, le dernier événement généré par celui-ci est l'événement du système de fichiers, ce qui fait avancer la hiérarchie.

4. plymouth – Ce processus s'exécute au démarrage de mountall et est chargé d'afficher l'écran noir qui s'affiche au démarrage du système, affichant quelque chose comme ci-dessous :

5. Plymouth-Ready – Indique que Plymouth est opérationnel.

Voici les processus principaux, d'autres qui s'exécutent également au démarrage, comme udev-fallback-graphics, etc. Pour revenir à la hiérarchie de démarrage, en un mot, les événements et les processus qui suivent sont dans l'ordre :

1. init avec génération d'un événement de démarrage.

2. mountall montant les systèmes de fichiers, plymouth (avec le démarrage de mountall) affichant l'écran de démarrage et kmod chargeant les modules du noyau.

3. Événement local-filesystem généré par mountall provoquant l'exécution de dbus. (Dbus est le bus de messages à l'échelle du système qui crée un socket permettant aux autres processus de communiquer entre eux en envoyant des messages à ce socket et le récepteur écoute les messages sur ce socket et filtre ceux qui lui sont destinés).

4. Le système de fichiers local ainsi que l'événement dbus démarré et l'événement de réseau statique provoqués par le réseau de processus qui s'exécute également sur l'événement du système de fichiers local entraînent l'exécution du gestionnaire de réseau.

5. L'événement système de fichiers virtuel généré par mountall provoque l'exécution d'udev. (udev est le gestionnaire de périphériques pour Linux qui gère le branchement à chaud des périphériques et est responsable de la création des fichiers dans le répertoire /dev et de leur gestion également.) udev crée des fichiers pour la RAM, la rom, etc. dans le répertoire /dev, ceux que le mountall a fini de monter virtuel -filesystems et a généré l'événement virtual-filesystem signifiant le montage du répertoire /dev.

6. udev provoque l'exécution de upstart-udev-bridge, ce qui signifie que le réseau local est opérationnel. Ensuite, une fois que mountall a fini de monter le dernier système de fichiers et a généré un événement de système de fichiers.

7. L'événement filesystem ainsi que l'événement static-network-up entraînent l'exécution du travail rc-sysinit. Ici, vient la compatibilité ascendante entre les anciens sysvinit et les nouveaux arrivants…

9. rc-sysinit exécute la commande telinit qui indique le niveau d'exécution du système.

10. Après avoir obtenu le niveau d'exécution, init exécute les scripts qui commencent par 'S' ou 'K' (en démarrant les tâches qui ont 'S' dans début de leur nom et en tuant ceux ayant 'K' au début de leur nom) dans le répertoire /etc/rcX.d (où 'X' est le niveau d'exécution actuel) .

Ce petit ensemble d’événements provoque le démarrage du système à chaque mise sous tension. Et ce déclenchement événementiel des processus est le seul responsable de la création de la hiérarchie.

Maintenant, un autre module complémentaire ci-dessus est la cause de l'événement. Quel processus provoque quel événement est également spécifié dans ce même fichier de configuration du processus, comme indiqué ci-dessous dans ces lignes :

Ci-dessus se trouve une section du fichier de configuration du processus mountall. Cela montre les événements qu'il émet. Le nom de l'événement succède au mot « événement ». L'événement peut être soit celui défini dans le fichier de configuration comme ci-dessus, soit le nom du processus accompagné du préfixe « démarrage », « démarré », « arrêt » ou « arrêté ».

Nous définissons donc ici deux termes :

  1. Générateur d'événements : celui qui a la ligne « émet xxx » dans son fichier de configuration, où xxx est le nom de l'événement qu'il possède ou génère.
  2. Event Catcher : celui dont la condition de démarrage ou d'arrêt est xxx ou qui démarre ou s'arrête sur l'événement généré par l'un des générateurs d'événements.

Ainsi, la hiérarchie suit et donc la dépendance entre les processus :

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

Ajouter de la complexité à la hiérarchie

Jusqu'à présent, vous devez avoir compris comment la hiérarchie de dépendance parent-enfant entre les processus est établie par un mécanisme de déclenchement d'événements via un simple mécanisme de démarrage.

Or, cette hiérarchie n’est jamais une relation individuelle n’ayant qu’un seul parent pour un enfant. Dans cette hiérarchie, nous pouvons avoir un ou plusieurs parents pour un enfant ou un processus étant parent de plusieurs enfants. Comment cela est-il réalisé ?? Eh bien, la réponse réside dans les fichiers de configuration eux-mêmes.

Ces lignes sont tirées du processus – mise en réseau et ici la condition de démarrage semble un peu trop complexe composée de nombreux événements à savoir – systèmes de fichiers locaux, udevtrigger, conteneur, niveau d'exécution, réseau.

Les systèmes de fichiers locaux sont émis par mountall, udevtrigger est le nom du travail, l'événement de conteneur est émis par conteneur-detect, l'événement de niveau d'exécution émis par rc-sysinit et la mise en réseau est à nouveau un travail.

Ainsi, dans une hiérarchie, la mise en réseau des processus est l'enfant de mountall, udevtrigger et containers-detect car elle ne peut pas continuer son fonctionnement (le fonctionnement du processus correspond à toutes les lignes définies dans les sections script ou exec dans le fichier de configuration du processus). jusqu'à ce que les processus ci-dessus génèrent leurs événements.
De même, nous pouvons avoir un processus parent de plusieurs processus si l'événement généré par un processus est mis en cache par plusieurs.

Distinguer les types d'emploi

Comme défini précédemment, nous pouvons avoir soit des emplois de courte durée (ou travailler et mourir) ou des emplois de longue durée (ou rester et travailler), mais comment faire la distinction entre eux??

Les tâches qui ont à la fois les conditions « démarrer le » et « arrêter le » spécifiées dans leurs fichiers de configuration et qui ont le mot « tâche » dans leur le fichier de configuration sont des tâches work-and-die qui démarrent sur l'événement généré, exécutent leur script ou leur section d'exécution (pendant l'exécution, ils bloquent les événements qui les ont provoqués) et meurent ensuite en libérant les événements qu'ils ont bloqués .

Les tâches qui n'ont pas de condition « arrêt activé » dans leur fichier de configuration sont des tâches de longue durée ou de séjour et de travail et elles ne meurent jamais. Désormais, les emplois de séjour et de travail peuvent être classés comme suit :

  1. Ceux qui n’ont pas de condition de réapparition et peuvent être tués par l’utilisateur root.
  2. Ceux qui ont une condition de réapparition dans leur fichier de configuration et redémarrent donc après avoir été tués à moins que leur travail ne soit terminé.

Conclusion

Ainsi, chaque processus dans LINUX dépend de certains et a certains processus qui en dépendent et cette relation est plusieurs sur plusieurs et est spécifiée avec le système de démarrage avec d'autres détails du processus.