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-enabled $daemon.service	Permet de voir si $daemon est actif au démarrage du système
chkconfig $daemon --list	systemctl list-units --type=service --all	Permet de voir la liste des services et s'ils sont actifs ou non 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 !

Nous allons maintenant 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

Configuration des unités

On peut afficher les fichiers de configuration des unités	# systemctl list-unit-files Cette commande affiche tous les fichiers, même ceux des unités qui ne sont pas actuellement chargées !
Il est possible de voir la configuration d'une unité	# systemctl cat sshd.service
Il est possible d'éditer la configuration d'une unité en utilisant edit. Cela va créer un répertoire portant le nom de l'unité et se terminant par un .d. Par exemple pour Apache, cela créer un répertoire /etc/systemd/system/httpd.service.d. Les informations présentes dans ce fichier vont venir surcharger les informations déjà présentes dans le fichier original. Pour modifier directement la configuration original, il faut utiliser l'option --full. Pour effacer une configuration additionnelle (surcharge), il suffit de supprimer le répertoire en .d. Une fois les modifications faite, il ne faut pas oublier de recharger systemD !	# systemctl edit sshd.service # systemctl edit sshd.service --full # systemctl daemon-reload
On peut également voir les dépendances d'une unité	# systemctl list-dependencies sshd.service
On peut également voir l'inverse, c'est à dire quand l'unité est requise. On voit que le service sshd démarre en mode console (multi-user.target) et en mode graphique (graphical.target). Nous aurions, au temps de SysVInit, parlé des runlevel 3 et 5.	# systemctl list-dependencies --reverse sshd.service sshd.service ● └─multi-user.target ● └─graphical.target
On peut demander les propriétés d'une unité Il est même possible de demander une propriété en particulier	# systemctl show sshd.service # systemctl show sshd.service -p WantedBy WantedBy=multi-user.target
Il est possible de masquer des unités, c'est à dire d'empêcher le démarrage manuel et automatique de l'unité. Il suffit alors de la démasquer pour pouvoir l'utiliser à nouveau	# systemctl mask httpd.service Created symlink from /etc/systemd/system/httpd.service to /dev/null. # systemctl start httpd.service Failed to start httpd.service: Unit is masked. # systemctl unmask httpd.service Removed symlink /etc/systemd/system/httpd.service. # systemctl start httpd.service

Les cibles

Aperçu

Les cibles reprennent le concept des runlevel de SysVInit :

# find / -name "runlevel*.target"
/usr/lib/systemd/system/runlevel5.target
/usr/lib/systemd/system/runlevel0.target
/usr/lib/systemd/system/runlevel6.target
/usr/lib/systemd/system/runlevel1.target
/usr/lib/systemd/system/runlevel2.target
/usr/lib/systemd/system/runlevel3.target
/usr/lib/systemd/system/runlevel4.target

On voit qu'il y en a 6 et voici leur utilité :

Run Level	Target (unité SystemD)	Description
0	runlevel0.target, poweroff.target	Arrêt du système
1	runlevel1.target, rescue.target	Démarrage du système avec un shell de secours
2,3,4	runlevel[2,3,4].target, multi-user.target	Démarrage du système en mode console
5	runlevel.target, graphical.target	Démarrage du système en mode graphique
6	runlevel.target, reboot.target	Redémarrage du système

On peut voir les liens symboliques qui sont fait sur les targets :

# ls -l /usr/lib/systemd/system/*.target | grep runlevel
lrwxrwxrwx. 1 root root  15 26 déc.  20:23 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root  13 26 déc.  20:23 /usr/lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root  17 26 déc.  20:23 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root  17 26 déc.  20:23 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root  17 26 déc.  20:23 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root  16 26 déc.  20:23 /usr/lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root  13 26 déc.  20:23 /usr/lib/systemd/system/runlevel6.target -> reboot.target

Cible courante

Pour voir la target courante ou anciennement la commande runlevel :

# systemctl get-default
multi-user.target
# runlevel
N 3

Changement de cible

Enfin, on peut changer la target courante grâce à l'option isolate :

# systemctl isolate graphical.target

Quand l'option isolate est utilisée, le suffixe .target n'est pas obligatoire.

Certaine target on des racourcis :

# systemctl isolate poweroff.target

équivaut à

# poweroff

# systemctl isolate reboot.target

équivaut à

# reboot

Changer la cible par défaut

La cible par défaut se trouve dans le répertoire /etc/systemd/system :

# ll /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 37 26 déc.  20:29 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

Il suffit de remplacer le lien symbolique pour modifier la cible par défaut !

# ln -fs /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Ou, plus simple, on peut utiliser l'option set-default :

# systemctl set-default graphical.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target.

Comme avec init on évitera de mettre poweroff.target et reboot.target comme cible par défaut...

Gestion des points de montage

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 !