Analyse approfondie du système de gestion systemd sous CentOS 7

Processus de démarrage du système CentOS :

POST --> Séquence de démarrage --> Chargeur de démarrage --> noyau + initramfs(initrd) -->

programme innit :

CentOS 5 : initialisation SysV

CetnOS 6 : Parvenu

CentOS 7 : Systèmed

Nouvelles fonctionnalités de Systemd :

Scripts d'initialisation System Sys V et LSB compatibles

Réaliser un démarrage parallèle des services au démarrage du système ; Utiliser l'activation socket/D-Bus et d'autres technologies pour démarrer les services ; Afin de réduire le temps de démarrage du système, l'objectif de systemd est : démarrer le moins de processus possible ; pour paralléliser autant de processus que possible Démarrer

Activer les processus à la demande ; Systemd peut offrir la possibilité de démarrer à la demande, en démarrant un service uniquement lorsqu'il est réellement demandé. Lorsque le service se termine, systemd peut l'arrêter et le redémarrer la prochaine fois que cela est nécessaire.

Possibilité de prendre un instantané et de restaurer le système  ;

Démarrer la gestion des points de montage et des points de montage automatiques :

Systemd gère automatiquement les points de montage sur le système pour pouvoir les monter automatiquement au démarrage du système. Et compatible avec le fichier /etc/fstab ;

Implémenter la gestion des dépendances des transactions :

systemd maintient un concept de « cohérence des transactions » pour garantir que tous les services associés peuvent démarrer normalement sans interdépendance ni blocage.

Définir une logique de contrôle des services basée sur des dépendances endogènes  ;

system utilise la fonctionnalité du noyau Linux, à savoir CGroup, pour effectuer la tâche de suivi des processus. Lors de l'arrêt du service, en interrogeant le CGroup, systemd peut s'assurer que tous les processus associés sont trouvés, arrêtant ainsi proprement le service

 ;

Service de journalisation : systemd est livré avec son propre service de journalisation journald, conçu pour surmonter les lacunes du service syslog existant.

Concepts de base du système

Concept d'unité :

De nombreuses choses doivent être faites pour l’initialisation du système. Les services d'arrière-plan doivent être démarrés, comme le démarrage du service SSHD ; un travail de configuration doit être effectué, comme le montage du système de fichiers. Chaque étape de ce processus est résumée par systemd dans une unité de configuration, c'est-à-dire une unité. Vous pouvez considérer un service comme une unité de configuration, un point de montage comme une unité de configuration, la configuration d'une partition d'échange comme une unité de configuration, etc. systemd classe les ruches en différents types : Cependant, systemd évolue rapidement et de nouvelles fonctionnalités sont ajoutées constamment. Les types de ruches pourraient donc continuer à augmenter dans un avenir proche.

service : représente un processus de service en arrière-plan, tel que mysqld. Il s'agit d'une catégorie couramment utilisée ;

socket : Cette ruche encapsule un socket dans le système et Internet. Actuellement, systemd prend en charge les sockets AF_INET, AF_INET6 et AF_UNIX pour le streaming, les paquets et les paquets continus. Chaque ruche de sockets possède une ruche de service correspondante. Le service correspondant sera démarré lorsque la première "connexion" entrera dans le socket (par exemple : nscd.socket démarre nscd.service après une nouvelle connexion).

device : cette ruche encapsule un périphérique qui existe dans l’arborescence des périphériques Linux. Chaque appareil marqué avec une règle udev apparaîtra dans systemd en tant que ruche d'appareils.

mount : ce type de ruche encapsule un point de montage dans la hiérarchie de la structure du système de fichiers. Systemd surveillera et gérera ce point de montage. Par exemple, il peut être automatiquement monté au démarrage ; il peut être automatiquement désinstallé sous certaines conditions. Systemd convertira toutes les entrées de /etc/fstab en points de montage et les traitera au démarrage.

montage automatique : ce type de ruche encapsule un point d'auto-montage dans la hiérarchie de la structure du système. Chaque ruche à montage automatique correspond à une ruche de montage Lorsque l'on accède au point de montage automatique, systemd exécute le comportement de montage défini dans le point de montage.

swap : Semblable à la ruche de montage, la ruche de swap est utilisée pour gérer la partition de swap. Les utilisateurs peuvent utiliser des ruches d'échange pour définir des partitions d'échange dans le système, permettant ainsi à ces partitions d'échange d'être activées au moment du démarrage.

cible : Cette ruche est un regroupement logique d’autres ruches. En réalité, ils ne font rien eux-mêmes, ils font simplement référence à d’autres ruches. Cela permet un contrôle unifié de l’unité de configuration. Cela permet de mettre en œuvre le concept familier des niveaux d'exécution. Par exemple, si vous souhaitez que le système passe en mode graphique, vous devez exécuter de nombreux services et commandes de configuration. Ces opérations sont représentées par des unités de configuration une par une. La combinaison de toutes ces unités de configuration dans une cible signifie que toutes ces unités de configuration doivent le faire. être exécuté une fois pour entrer dans l’état de fonctionnement du système représenté par la cible. (Par exemple : multi-user.target équivaut au niveau d'exécution 3 dans les systèmes utilisant SysV traditionnel)

timer : L'unité de configuration du timer est utilisée pour déclencher des opérations définies par l'utilisateur à intervalles réguliers. Ce type d'unité de configuration remplace les services de synchronisation traditionnels tels que atd et crond.

instantané : Semblable à une ruche cible, un instantané est un ensemble de ruches. Il enregistre l'état de fonctionnement actuel du système.

Dépendances :

Bien que systemd supprime la dépendance à l'égard d'un grand nombre de tâches de démarrage afin qu'elles puissent être démarrées simultanément. Cependant, certaines tâches ont encore des dépendances inhérentes entre elles, et les trois méthodes principales d'« activation de socket » (activation de socket), d'activation de D-Bus et d'autofs ne peuvent pas être utilisées pour soulager la dépendance (voir les descriptions suivantes pour plus de détails sur les trois grandes méthodes). Par exemple : le montage doit attendre que le point de montage soit créé dans le système de fichiers ; le montage doit également attendre que le périphérique physique correspondant soit prêt. Afin de résoudre ce type de problème de dépendance, les ruches systemd peuvent définir des dépendances les unes sur les autres.

Systemd utilise des mots-clés dans les fichiers de définition de ruche pour décrire les dépendances entre les ruches. Par exemple : l'unité A dépend de l'unité B, qui peut être représentée par « exiger A » dans la définition de l'unité B. De cette façon, systemd garantira que A est démarré en premier, puis B.

Transactions système :

Systemd peut garantir l'intégrité des transactions. Le concept de transaction de Systemd est différent de celui de la base de données, principalement pour garantir qu'il n'y a pas de références circulaires entre plusieurs unités de configuration dépendantes. S'il existe une dépendance circulaire, systemd ne pourra démarrer aucun service. À ce stade, systemd essaiera de résoudre ce problème, car il existe deux types de dépendances entre les ruches : require est une dépendance forte ; wanted est une dépendance faible. systemd supprimera la dépendance spécifiée par le mot-clé wanted pour voir si elle peut rompre le problème. faire du vélo. S'il ne peut pas être réparé, systemd signalera une erreur.

Systemd peut détecter et réparer automatiquement de telles erreurs de configuration, réduisant ainsi considérablement la charge de dépannage de l'administrateur.

Cible et niveau d'exécution :

systemd remplace le concept de niveau d'exécution par cible, offrant une plus grande flexibilité. Par exemple, vous pouvez hériter d'une cible existante et ajouter d'autres services pour créer votre propre cible. Le tableau suivant répertorie les relations correspondantes entre les cibles sous systemd et les niveaux d'exécution courants :

Le principe de démarrage simultané de Systemd

Comme mentionné précédemment, dans Systemd, tous les services sont démarrés simultanément, tels qu'Avahi, D-Bus, livirtd, X11 et HAL peuvent être démarrés en même temps. À première vue, cela semble être un problème. Par exemple, Avahi a besoin du service syslog et Avahi est démarré en même temps. En supposant qu'Avahi démarre plus rapidement, syslog n'est pas encore prêt, mais Avahi doit enregistrer. les journaux. Cela ne poserait-il pas des problèmes ?

Les développeurs de Systemd ont soigneusement étudié la nature de l'interdépendance entre les services et ont découvert que les soi-disant dépendances peuvent être divisées en trois types spécifiques, et que chaque type peut en fait éliminer les dépendances grâce aux technologies correspondantes.

L'un des principes du démarrage simultané : résoudre socket dépendances

La grande majorité des dépendances de service sont des dépendances de socket. Par exemple, le service A fournit ses propres services via un port socket S1. Si d'autres services ont besoin du service A, ils doivent se connecter à S1. Ainsi, si le service A n'a pas encore été démarré, S1 n'existe pas et les autres services recevront des erreurs de démarrage. Ainsi, traditionnellement, les utilisateurs doivent d'abord démarrer le service A, attendre qu'il entre dans l'état prêt, puis démarrer les autres services qui en ont besoin. Systemd pense que tant que nous établissons S1 à l'avance, tous les autres services peuvent être démarrés en même temps sans attendre que le service A crée S1. Si le service A n'a pas été démarré, alors la demande de service envoyée par d'autres processus à S1 sera en fait mise en cache par le système d'exploitation Linux et les autres processus attendront à l'emplacement de cette demande. Une fois le service A opérationnel, les requêtes mises en cache peuvent être traitées immédiatement et tout commence à fonctionner normalement.

Alors, comment le service utilise-t-il le socket créé par le processus init ?

Le système d'exploitation Linux a une fonctionnalité. Lorsqu'un processus appelle fork ou exec pour créer un processus enfant, tous les descripteurs de fichiers ouverts dans le processus parent sont hérités par le processus enfant. Un socket est également une sorte de descripteur de fichier. Le processus A peut créer un socket. Après cela, lorsque le processus A appelle exec pour démarrer un nouveau processus enfant, tant que l'indicateur close_on_exec du socket est effacé, alors le nouveau processus enfant est You. peut hériter de ce socket. Le socket vu par le processus enfant et le socket créé par le processus parent sont le même socket système, comme si le socket avait été créé par le processus enfant lui-même, il n'y a aucune différence.

Cette fonctionnalité était auparavant exploitée par un service système appelé inetd. Le processus Inetd est responsable de la surveillance de certains ports de socket courants, tels que Telnet. Lorsqu'il y a une demande de connexion sur le port, inetd démarre le processus telnetd et transmet le socket connecté au nouveau processus telnetd pour traitement. De cette façon, lorsque le système ne dispose pas d'une connexion client telnet, il n'est pas nécessaire de démarrer le processus telnetd. Inetd peut proxy de nombreux services réseau, ce qui peut économiser beaucoup de charge système et de ressources mémoire. Le service correspondant ne sera démarré qu'en cas de demande de connexion réelle, et le socket sera transmis au processus de service correspondant.

Semblable à inetd, systemd est le processus parent de tous les autres processus. Il peut d'abord établir toutes les sockets requises, puis transmettre le socket au nouveau processus de service lors de l'appel à exec, et le nouveau processus utilise directement le socket. téléphoner et effectuer le service.

Principe 2 du démarrage simultané : Résoudre les dépendances D-Bus

D-Bus est l'abréviation de Desktop-Bus, qui est un mécanisme de communication inter-processus avec une faible latence, une faible surcharge et une haute disponibilité. Il est de plus en plus utilisé pour la communication entre applications, mais également pour la communication entre les applications et le noyau du système d'exploitation. De nombreux processus de service modernes utilisent D-Bus au lieu de sockets comme mécanisme de communication inter-processus pour fournir des services externes. Par exemple, le service NetworkManager qui simplifie la configuration du réseau Linux utilise D-Bus pour interagir avec d'autres applications ou services : l'évolution du logiciel client de messagerie peut obtenir des changements d'état du réseau du service NetworkManager via D-Bus afin de les gérer en conséquence.

D-Bus prend en charge la fonction dite "busactivation". Si le service A doit utiliser le service D-Bus du service B et que le service B n'est pas en cours d'exécution, D-Bus peut démarrer automatiquement le service B lorsque le service A demande le D-Bus du service B. La requête émise par le service A sera mise en cache par D-Bus et le service A attendra que le service B soit prêt. Grâce à cette fonctionnalité, les services qui reposent sur D-Bus peuvent être démarrés en parallèle.

Principe 3 du démarrage simultané : résolution des dépendances du système de fichiers

Pendant le processus de démarrage du système, les activités liées au système de fichiers prennent le plus de temps. Par exemple, le montage du système de fichiers, la vérification du disque (fsck) sur le système de fichiers, la vérification des quotas de disque, etc. opérations. En attendant la fin de ce travail, le système reste inactif. Les services qui souhaitent utiliser le système de fichiers semblent devoir attendre la fin de l'initialisation du système de fichiers avant de pouvoir démarrer. Mais systemd a découvert que cette dépendance pouvait également être évitée.

Systemd fait référence aux idées de conception d'autofs, permettant aux services qui s'appuient sur le système de fichiers et à l'initialisation du système de fichiers lui-même de fonctionner simultanément. autofs peut détecter quand un point de montage du système de fichiers est réellement accédé avant de déclencher l'opération de montage. Ceci est réalisé grâce à la prise en charge du module de montage automatique du noyau. Par exemple, lorsqu'un appel système open() est exécuté sur "/misc/cd/file1", /misc/cd n'a pas encore effectué l'opération de montage. À ce stade, l'appel open() est suspendu et attend. le noyau informe autofs et autofs effectue l'opération de montage. A ce moment, le contrôle est rendu à l'appel système open() et le fichier est ouvert normalement.

Systemd intègre l'implémentation d'autofs. Pour les points de montage dans le système, tels que /home, lorsque le système démarre, systemd crée un point de montage automatique temporaire pour celui-ci. À l'heure actuelle, le véritable périphérique de montage de /home n'a pas encore été démarré, l'opération de montage réelle n'a pas été effectuée et la détection du système de fichiers n'est pas terminée. Cependant, les processus qui dépendent de ce répertoire peuvent déjà être démarrés simultanément et leurs opérations open() sont capturées par autofs intégré à systemd, qui suspend l'appel open() (ce qui peut interrompre l'état de veille). Ensuite, après avoir attendu la fin de l'opération de montage réelle et la fin de la détection du système de fichiers, systemd remplace le point de montage automatique par le point de montage réel et laisse l'appel open() revenir. Par conséquent, les services qui dépendent du système de fichiers et du système de fichiers lui-même peuvent être démarrés simultanément.

Bien sûr, la dépendance au répertoire racine "/" doit en fait être exécutée en série, car systemd lui-même est également stocké sous / et doit attendre que le répertoire racine du système soit monté et vérifié.

Cependant, pour les points de montage tels que /home, cette simultanéité peut améliorer la vitesse de démarrage du système, en particulier lorsque /home est un nœud NFS distant, ou un disque chiffré, etc., qui prend beaucoup de temps pour être prêt. de démarrage simultané, le système n'a rien à faire pendant cette période, au lieu de cela, il peut utiliser ce temps libre pour effectuer davantage de processus de démarrage, ce qui réduit généralement le temps de démarrage du système.

Systemd Utilisation

Ce qui suit est une brève introduction à l'utilisation de systemd pour les différents rôles du personnel technique. Cet article a uniquement pour but de donner une description simple pour vous donner une compréhension générale de l'utilisation de systemd. Il y a trop de détails spécifiques pour être abordés dans un court article. Les lecteurs doivent consulter eux-mêmes la documentation systemd.

Unité Écriture de fichiers

Lorsque les développeurs développent un nouveau programme de service, tel que httpd, ils doivent écrire un fichier ruche pour celui-ci afin que le service puisse être géré par systemd, similaire au fichier de configuration de travail d'UpStart. Définissez la syntaxe de ligne de commande pour le démarrage du service dans ce fichier, ainsi que les dépendances sur d'autres services.

De plus, nous avons déjà appris que systemd avait de nombreuses fonctions. Il n'est pas seulement utilisé pour gérer les services, mais aussi pour gérer les points de montage, définir des tâches planifiées, etc. Ces tâches sont complétées en éditant le fichier ruche correspondant. Je donne ici quelques exemples de fichiers ruche.

Ce qui suit est le fichier d'unité de configuration du service SSH. Le fichier d'unité de configuration du service a .service comme suffixe de nom de fichier.

[root@kalaguiyin system]# cat/usr/lib/systemd/system/sshd.service

[Unité]

Description=Démon du serveur OpenSSH

Après=network.target sshd-keygen.service

Wants=sshd-keygen.service

Pièce #[unité], informations de description

[Services]

EnvironmentFile=/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=processus

Redémarrage = en cas d'échec

RestartSec=42s

#[service] définition, ExecStartPre définit la commande qui doit être exécutée avant de démarrer le service

;

#ExecStart définit la syntaxe de ligne de commande spécifique pour démarrer le service.

[Installer]

WantedBy=multi-user.target

Section #[install] : WangtedBy indique que ce service est requis en mode multi-utilisateurs.

Jetons ensuite un œil à multi-user.target :

[root@kalaguiyin system]#catmulti-user.target

[Unité]

Description=Système multi-utilisateurs

Documentation=man:systemd.special(7)

Requires=basic.target

Conflicts=rescue.service Rescue.target

After=basic.target Rescue.servicerescue.target

AllowIsolate=oui

# La définition Requires indique que lorsque multi-user.target démarre, basic.target doit également être démarré de plus, lorsque basic.target s'arrête, multi-user.target doit également s'arrêter ; Si vous regardez ensuite le fichier basic.target, vous constaterez qu'il spécifie également sysinit.target

# Les autres unités doivent être démarrées en conséquence. De même, sysinit.target contiendra également d'autres unités. En utilisant une telle structure de liaison couche par couche, tous les services de composants devant prendre en charge le mode multi-utilisateurs seront finalement initialisés et démarrés.

[Installer]

Alias=default.target

# Définition de l'alias, c'est-à-dire définir l'alias de cette unité, afin que vous puissiez utiliser cet alias pour référencer cette unité lors de l'exécution de systemctl.

De plus, vous pouvez également voir des répertoires tels que *.wants dans le répertoire /etc/systemd/system. Le fichier d'unité de configuration placé dans ce répertoire est équivalent au mot-clé wanted dans la section [Unit], c'est-à-dire lorsque cela. L'unité démarre. Ces unités doivent également être démarrées. Par exemple, vous pouvez simplement placer le fichier foo.service que vous avez écrit vous-même dans le répertoire multi-user.target.wants, afin qu'il soit démarré par défaut à chaque fois.

[système root@kalaguiyin]#pwd

/etc/systemd/system

[système root@kalaguiyin]#ls

basic.target.wans                                                                                                                                                                                                             display-manager.service                   

bluetooth.target.wans                                                                                                                

dbus-org.bluez.service           graphical.target.wants

printer.target.wans                                                                                                                                                                                                                                                                              prises.

spice-vdagentd.target.wans                                                                                                default.target .veut

Regardons à nouveau le fichier sys-kernel-debug.mout. Ce fichier définit un point de montage de fichier :

.

[système root@kalaguiyin]#cat

sys-kernel-debug.mount

[Unité]

Description=Système de fichiers de débogage

Documentation=https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt

Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

DefaultDependencies=non

ConditionPathExists=/sys/kernel/debug

Avant=sysinit.target

[Monture]

Quoi=debugfs

Où=/sys/kernel/debug

Type=debugfs

Ce fichier ruche définit un point de montage. Le fichier ruche de montage comporte une section de configuration [Mount], qui contient trois éléments de données : Quoi, Où et Type. Ceux-ci sont nécessaires à la commande mount. La configuration dans l'exemple est équivalente à la commande mount suivante :

mount –t debugfs /sys/kernel/debug debugfs

SystemdGestion du système :

Le principal outil de ligne de commande de

systemd est systemctl.

La plupart des administrateurs devraient déjà être très familiers avec la gestion des services système et des systèmes d'initialisation, comme l'utilisation des commandes service, chkconfig et telinit. systemd effectue également les mêmes tâches de gestion, mais la syntaxe de l'outil de commande systemctl est différente.

Démarrer le service

systemctl démarre httpd.service comme indiqué dans la figure 1 :

Arrêter le service

systemctl arrête httpd.service comme le montre la figure 2 :

Redémarrer le service

systemctl restarthttpd.service comme le montre la figure 3 :

Service de rechargement

systemctl reloadhttpd.service

Redémarrage conditionnel

systemctl condrestarthttpd.service

Vérification du statut

statut systemctlhttpd.service

Liste des services pouvant être démarrés ou arrêtés.

systemctl list-unit-files –type=service

Définir le service pour qu'il démarre au démarrage

chkconfig httpd sur

systemctl activerhttpd.service

Annuler le démarrage du service ;

systemctl désactiverhttpd.service

Vérifiez si un service est configuré pour être activé ou désactivé dans l'environnement actuel.

systemctl is-enabledhttpd.service;echo $?

Sortie de l'activation et de la désactivation des services à chaque niveau d'exécution

systemctl list-unit-files –type=service

Répertorie les niveaux d'exécution auxquels un service est activé et désactivé.

ls /etc/lib/systemd/system/*.wants/httpd.service

Changer le niveau d'exécution de l'utilisateur :

systemctl isolatemulti-user.target

multi-user.target == 3ème niveau d'exécution

graphical.target == 5ème niveau d'exécution

Lien symbolique runlevel3.target, pointant vers multi-user.target

Lien symbolique runlevel5.target, pointant vers Graphical.target

Modifier le niveau d'exécution par défaut :

[root@kalaguiyinsystem]# systemctl set-default multi-user.target

rm'/etc/systemd/system/default.target'

ln -s'/usr/lib/systemd/system/multi-user.target''/etc/systemd/system/default.target'

L'essence de l'opération ci-dessus est de supprimer /usr/lib/systemd/system/default.target, puis de lier le fichier cible de niveau cible au fichier /etc/systemd/system/default.target ;

systemd est plus qu'un simple système d'initialisation :

systemd est également responsable d'autres configurations de gestion du système, telles que la configuration du réseau, la gestion Locale , la gestion du chargement des modules du noyau système, etc.

Systemd fait un excellent travail en remplaçant toutes les fonctionnalités de sysvinit, mais il ne fait pas preuve de complaisance. Étant donné que le processus init est le processus parent de tous les processus du système, systemd est très approprié pour fournir des fonctions autrefois fournies par d'autres services, telles que les tâches planifiées (précédemment complétées par la gestion de session crond (précédemment gérées par ConsoleKit/PolKit, etc) ; .). À en juger par l'introduction superficielle de cet article, Systemd s'est déjà occupé de beaucoup de choses, mais il est encore en développement. Il deviendra progressivement un environnement système multifonctionnel capable de gérer de nombreuses tâches de gestion système. Certains le considèrent même comme un système d'exploitation. C’est très utile pour standardiser la gestion Linux !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!