Différences entre versions de « Systemctl »
| Ligne 67 : | Ligne 67 : | ||
||systemctl is-failed $daemon.service | ||systemctl is-failed $daemon.service | ||
||Retourne la valeur ''active'' si le service fonctionne sinon ''failed'' | ||Retourne la valeur ''active'' si le service fonctionne sinon ''failed'' | ||
| + | |- | ||
|align="center"|X | |align="center"|X | ||
| − | ||systemctl list-units | + | ||systemctl list-units [--all] [--state=inactive] [--type=service] |
| − | ||Liste toutes les | + | ||Liste toutes les ''unités'' gérées par ''systemctl'' |
|} | |} | ||
| + | Il est possible de ne pas ajouter le ''.service'', ''systemctl'' comprendra très bien qu'il s'agit d'un service ! | ||
| + | = Systemctl = | ||
Version du 27 décembre 2017 à 21:16
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 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 |
| X | systemctl list-units [--all] [--state=inactive] [--type=service] | Liste toutes les unités gérées par systemctl |
Il est possible de ne pas ajouter le .service, systemctl comprendra très bien qu'il s'agit d'un service !