Systemctl

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 !

Systemctl

Nous allons passer en revue les unités que nous pouvons manipuler avec systemctl !

Gestion des unités

État des unités

systemctl peut afficher des informations sur les unités :

# systemctl list-units

Et on peut appliquer des filtre sur cette commande :

• --type : pour spécifier le type d'unité
  • mount : les points de montage
  • service : les démons
  • target : les runlevel ou événements
  • scope : les sessions actives
  • device : les périphériques
• --state
  • loaded : fichier de configuration lu par systemD
  • active : l'unité est active
  • inactive : l'unité des inactive
• --all : toutes les unités

Par exemple, pour lister les points de montage actif :

# systemctl list-units --type=mount --state=active

Gestion des disques

systemctl est capable de gérer les points de montage et de monter automatiquement un emplacement physique dans un répertoire. Dans cet exemple, le disque sdb à déjà été partitionné et formaté, il ne reste plus qu'à le monter. Traditionnellement nous aurions utilisé la commande mount et modifié le fichier /etc/fstab pour rendre le point de montage persistant. Maintenant nous allons créer un fichier opt-sdb.mount dans le répertoire /etc/systemd/system/ :

[Unit]
Description=Deuxième disque

[Mount]
What=/dev/sdb1
Where=/opt/sdb
Type=ext4
Options=defaults

[Install]
WantedBy=local-fs.target

Maintenant que le fichier de montage est crée, on peut en informer systemctl :

# systemctl daemon-reload

et démarrer le point de montage :

# systemctl start opt-sdb.mount

Rien ne nous empêche, comme pour les services, de l'enregistrer au démarrage :

# systemctl enable opt-sdb.mount

On peut même contrôler l'état du point de montage :

# systemctl list-units --type=mount | grep opt-sdb
opt-sdb.mount           loaded active mounted Deuxième disque

Le nom du fichier doit absolument correspondre à la destination du point de montage sous peine d'avoir l'erreur suivante : systemd[1]: sdb.mount's Where= setting doesn't match. Par exemple, si votre point de montage est /opt/sdb le fichier doit s'appeler opt-sdb.mount !