Différences entre versions de « Systemctl »

De The Linux Craftsman
Aller à la navigation Aller à la recherche
Ligne 40 : Ligne 40 :
 
||Permet de recharger la configuration de $daemon
 
||Permet de recharger la configuration de $daemon
 
|-
 
|-
||X
+
|align="center"|X
 
||systemctl reload-or-restart $daemon
 
||systemctl reload-or-restart $daemon
 
||Permet de recharger ou redémarrer $daemon
 
||Permet de recharger ou redémarrer $daemon
Ligne 56 : Ligne 56 :
 
||Permet d'effacer $daemon du démarrage du système
 
||Permet d'effacer $daemon du démarrage du système
 
|-
 
|-
||chkconfig $daemon off
+
||chkconfig $daemon
||systemctl disable $daemon.service
+
||systemctl is-enable $daemon.service
||Permet d'effacer $daemon du démarrage du système
+
||Permet de voir si $daemon est actif au démarrage du système
 +
|-
 +
||chkconfig $daemon --list
 +
||systemctl is-enable $daemon.service
 +
||Permet de voir si $daemon est actif au démarrage du système
 +
|-
 +
|align="center"|X
 +
||systemctl is-failed $daemon.service
 +
||Retourne la valeur ''active'' si le service fonctionne sinon ''failed''
 
|}
 
|}

Version du 27 décembre 2017 à 20:36

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 :

Comparing services start.png

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 et plus 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.

Les sockets AF_UNIX ne nécessitent pas la présence d'un programme pour démarrer et sont donc créées par le système d'exploitation au démarrage. Les services démarrent en parallèle et se branchent à la socket quand ils sont prêt.

Maintenant, que faire ?

Ci-dessous un tableau qui fait le lien entre les anciennes et les nouvelles commandes :

SysVInit SystemD Description
service $daemon start systemctl start $daemon.service Permet de démarrer $daemon
service $daemon stop systemctl stop daemon.service Permet de stopper $daemon
service $daemon restart systemctl restart $daemon.service Permet de redémarrer $daemon
service $daemon reload systemctl reload $daemon.service Permet de recharger la configuration de $daemon
X systemctl reload-or-restart $daemon Permet de recharger ou redémarrer $daemon
service $daemon status systemctl status $daemon Affiche des informations sur le service $daemon
chkconfig $daemon on systemctl enable $daemon.service Permet d'enregistrer $daemon au démarrage du système
chkconfig $daemon off systemctl disable $daemon.service Permet d'effacer $daemon du démarrage du système
chkconfig $daemon systemctl is-enable $daemon.service Permet de voir si $daemon est actif au démarrage du système
chkconfig $daemon --list systemctl is-enable $daemon.service Permet de voir si $daemon est actif au démarrage du système
X systemctl is-failed $daemon.service Retourne la valeur active si le service fonctionne sinon failed