Des informations profondes du système «Ubuntu Linux» - voyons-nous ceci?

Linux Comme nous le savons, c'est un noyau et non un système d'exploitation, expédie avec plusieurs distributions comme: Debian, Feutre, Ubuntu etc. et beaucoup plus. Ubuntu OS développé par Mark Shuttleworth est populairement connu et largement utilisé par beaucoup. Aussi, étant libre et open source, sa nouvelle version est publiée chaque année, ce qui est apporté par des milliers de développeurs qui contribuent à son développement. Mais comment fonctionne-t-il? Ce que tous les processus, la liste des événements le font fonctionner et quelle est la signification de ces processus?

Cet article vous emmènerait un peu profondément dans les internes de Ubuntu os qui sont très intéressants et aideraient un novice à comprendre une compréhension complète de son fonctionnement.

Déposer le système

Linux a un processus pour son fonctionnement, chaque service système comprenant la gestion de l'alimentation, le démarrage, la gestion des accidents du système est un processus qui a un fichier de configuration dans "/ etc / init"Cela décrit l'événement sur lequel il exécutera et l'événement correspondant sur lequel il arrêterait son exécution, ainsi qu'il maintient également ses autres fichiers de configuration qui décrivent son comportement d'exécution dans le système"/etc/”Répertoire, faisant ainsi du système un événement piloté.

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

Versions antérieures Ubuntu avant 6.dix inclus sysvinit qui a été utilisé pour exécuter des scripts dans "/ etc / rcx.d”Répertoire sur chaque startup et arrêt du système. Mais après ça parvenu le système a remplacé l'ancien style sysvinit système, mais lui assure toujours une compatibilité en arrière.

Les dernières versions Ubuntu ont ce système de fin, mais depuis son évolution de Ubuntu 6.dix il a fait plusieurs révisions la version actuelle étant 1.13.2 Comme le 4 septembre 2014. Le dernier système UNSSTART a 2 init Processus, un pour les processus système et autres qui gère la session actuelle connectée en session et n'existe que jusqu'à ce que l'utilisateur soit connecté, également appelé X-Session init.

L'ensemble du système a été établi comme hiérarchique, consistant en une relation ancêtre.

Par exemple: Une petite relation hiérarchique entre les deux procédés d'initiés est: System init (1) -> Manager d'affichage (espace du noyau) -> Display Manager (espace utilisateur) -> User init (ou X-Session init).

Les fichiers de configuration des processus gérés par System init résident dans «/ etc / init»Et pour ceux gérés par Session Init résident dans«/ usr / share / upstart»(Selon les versions actuelles ci-dessus 1.12) et ces fichiers de configuration sont essentiels à de nombreux secrets déterrés sur les processus comme décrit dans cet article.

Approfondir la hiérarchie

Ubuntu reconnaît deux types de processus:

1. Emplois de courte durée (ou emplois au travail et à la die).
2. Emplois à long terme (ou emplois de séjour et de travail).

La hiérarchie faite sur le système est due à la relation de dépendance entre les processus que nous pouvons comprendre en affichant leurs fichiers de configuration. Commençons d'abord à partir d'une simple relation hiérarchique entre les processus qui font du système pour démarrer et comprendre la signification de chacun d'eux.

Hiérarchie de démarrage

Init est le premier processus pour commencer à alimenter le système et est classé sous travail et entrepôt Le travail car il n'est jamais tué et la seule fois où l'initiation est tuée.e. init ne meurt que et cela aussi une fois par session et c'est à l'allure. En mettant en disposition, init génère le tout premier événement du système I.e. événement de démarrage. Chaque fichier de configuration dans "/ etc / init"A deux lignes qui définissent l'événement qui fait démarrer le processus et s'arrêter. Ces lignes sont comme mises en évidence dans la figure ci-dessous:

Ceci est un fichier de configuration d'un processus failsafe-x Et ceux-ci commencent et s'arrêtent sur les conditions décrivant l'événement sur lequel le processus commencera. Sur la génération d'événements de démarrage par init procédé à l'initiale, les processus qui ont le démarrage comme démarrage à l'état 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 de l'init.

Les processus qui commencent sur le démarrage sont répertoriés comme sous et ce sont tous des emplois de travail et de die:

1. nom d'hôte - Ceci est un processus qui indique simplement au système de son nom d'hôte défini dans / etc / hostname Fichier.

2. kmod - Charge les modules du noyau i.e. Tous les pilotes du fichier / modules / 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 sur le démarrage, y compris les systèmes de fichiers locaux et les systèmes de fichiers distants.

Le / proc Le fichier est également monté par ce processus même et, après tous les travaux de montage, le dernier événement généré par It est un événement Systems qui fait avancer la hiérarchie plus loin.

4. plymouth - Ce processus s'exécute sur le démarrage de Mountall et est responsable de montrer cet écran noir qui est vu sur le démarrage du système montrant quelque chose comme ci-dessous:

5. Plymouth prêt pour Plymouth - Indique que Plymouth est en place.

Voici le processus principal, d'autres qui s'exécutent également au démarrage comprend, comme udev-fallback-graphics, etc. Revenons à la hiérarchie de démarrage, en un mot, les événements et les processus qui suivent sont comme en séquence:

1. init Avec la génération d'événements de démarrage.

2. Mountall Systèmes de fichiers de montage, Plymouth (ainsi que le démarrage du montall) affichant l'écran d'éclaboussure et les modules de noyau de chargement de KMOD.

3. système local Événement généré par Mountall provoquant l'exécution des DBU. (DBUS est le bus de messages à l'échelle du système qui crée une prise permettant à d'autres processus de communiquer les uns aux autres via l'envoi de messages à cette prise et le récepteur écoute les messages sur cette prise et filtre ceux destinés à cela).

4. système local Parallèlement à des DBU démarrés et à un événement de réseau statique causé par le réseau de processus qui s'exécute également sur l'événement local-fileSystem provoque l'exécution du réseau de réseau.

5. système virtuel L'événement généré par Mountall fait fonctionner Udev. (UDEV est le gestionnaire de périphériques de Linux qui gère le plagage à chaud des appareils et est responsable de la création de fichiers dans le répertoire / de dev.) UDEV crée des fichiers pour RAM, ROM, etc.

6. udev provoque l'exécution de Upstart-Udev-Bridge qui signifie que le réseau local est en place. Ensuite, après Mountall, il a terminé le montage du dernier système de fichiers et a généré un événement de système de fichiers.

7. système de fichiers L'événement avec un événement de réseau statique fait fonctionner le travail RC-Sysinit. Ici, vient la compatibilité en arrière entre le sysvinit plus âgé et le parvenu…

9. RC-Sysinit Exécute la commande Telinit qui indique au niveau du système.

dix. Après avoir obtenu le couloir, l'init exécute les scripts qui commencent par 'S' ou 'K'(Démarrer des emplois qui ontS«Au début de leur nom et tuer ceux qui ont»K'Au début de leur nom) dans le répertoire / etc / rcx.D (où 'X'est le niveau du couloir actuel).

Ce petit ensemble d'événements provoque le démarrage du système à chaque fois que vous l'alimentez. Et, ce déclenchement d'événements des processus est la seule chose 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 le même fichier de configuration du processus comme indiqué ci-dessous dans ces lignes:

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

Donc, ici, nous définissons 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. Capteur d'événements: Celui qui a son début ou d'arrêter la condition XXX ou qui commence ou s'arrête sur l'événement généré l'un des générateurs d'événements.

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

Générateur d'événements (parent) -> Catcher d'événements (enfant) 

Ajout de complexité à la hiérarchie

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

Maintenant, cette hiérarchie n'est jamais une relation individuelle ayant un seul parent pour un enfant. Dans cette hiérarchie, nous pouvons avoir un ou plusieurs parents pour un enfant ou un processus étant un parent de plus d'un enfant. Comment cela est accompli?? Eh bien, la réponse réside dans les fichiers de configuration lui-même.

Ces lignes sont tirées du processus - le réseautage et ici le début de condition semble un peu trop complexe composé de nombreux événements à savoir - système local, udevtrigger, récipient, courir, la mise en réseau.

Local-FileSystems est émis par Mountall, Udevtrigger est le nom de Job, l'événement en conteneur est émis par l'événement de détection de conteneurs et de couloir émis par RC-Sysinit, et le réseautage est à nouveau un travail.

Ainsi, dans une hiérarchie, le réseautage de processus est l'enfant de Mountall, Udevtrigger et la détection de conteneurs car il ne peut pas continuer son fonctionnement (le fonctionnement du processus est toutes les lignes définies sous des sections de script ou d'exécution 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 étant un parent de beaucoup si l'événement généré par un seul processus est mis en cache par beaucoup.

Distinguer les types d'emplois

Comme défini précédemment, nous pouvons avoir une courte durée (ou travail et die emplois) ou longue durée (ou séjour) emplois mais comment les distinguer??

Les emplois qui ont les deuxdémarrer' et 's'arrêter«Conditions spécifiées dans leurs fichiers de configuration et ont un mot»tâche«Dans leur fichier de configuration, sont travail et die Des emplois qui commencent sur l'événement généré, exécutent leur script ou leur section Exec (lors de l'exécution, ils bloquent les événements qui les ont causés) et meurent ensuite en libérant les événements qu'ils ont bloqués.

Ces emplois qui n'ont pass'arrêter«L'état dans leur fichier de configuration est de longue date ou séjour emplois et ils ne meurent jamais. Maintenant, les emplois de séjour et de travail peuvent être classés davantage comme:

1. Ceux qui n'ont pas l'état de réapparition et peuvent être tués par l'utilisateur racine.
2. Ceux qui ont réapparaissent l'état dans leur fichier de configuration et ils 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 possède certains processus qui en dépendent et cette relation est plusieurs sur plusieurs et est spécifiée avec le système de fin.