Différences entre versions de « Systemctl »
Ligne 9 : | Ligne 9 : | ||
Ci-dessous un dessin expliquant comment se déroule le démarrage du système : | Ci-dessous un dessin expliquant comment se déroule le démarrage du système : | ||
− | [[Fichier:Comparing services start.png|centré| | + | [[Fichier:Comparing services start.png|centré|500px]] |
+ | |||
== Explication de texte == | == Explication de texte == | ||
On voit clairement le gain de temps au démarrage du système ! Une question vient à l'esprit, comment est-ce possible ? | On voit clairement le gain de temps au démarrage du système ! Une question vient à l'esprit, comment est-ce possible ? |
Version du 27 décembre 2017 à 16:06
Introduction
Déni, Colère, Expression, Dépression, Acceptation
Nous étions habitués aux commandes service, chkconfig ou encore init mais maintenant c'est de l'histoire ancienne puisque SysVInit à été remplacé par SystemD, le nouveau gestionnaire de démarrage écrit par RedHat.
On peut se demander pourquoi on change un système qui fonctionne ?
La raison est simple : SysVInit est lent, mal architecturé, possède des faiblesses. C'en était trop pour certain et c'est pourquoi, d'une architecture modulaire (chacun sa tâche), nous sommes passé à une architecture centralisée (une seule commande). Ce nouveau moteur est écrit en C et permet un démarrage parallélisé des processus plutôt qu'en série. Les développeur d'Ubuntu avaient commencé le travail en écrivant UStart mais n'étaient pas allé jusqu'au bout des choses !
Ci-dessous un dessin expliquant comment se déroule le démarrage du système :
Explication de texte
On voit clairement le gain de temps au démarrage du système ! Une question vient à l'esprit, comment est-ce possible ? La réponse se trouve dans le type de socket utilisées pour la communication entres les services : on est passé de socket AF_INET, orienté réseaux, à des socket AF_UNIX, orientée système.
Le premier type de socket, AF_INET, permet des réseau entre les services, surtout utilisée dans les systèmes distribués n'est pas vraiment d'actualité sur un système centralisé. Ce qui explique cette migration vers des sockets AF_UNIX, qui sont des sockets système, c'est à dire un fichier.
Maintenant, que faire ?
Ci-dessous un tableau