Différences entre versions de « Systemctl »
(→Aperçu) |
|||
| (3 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 97 : | Ligne 97 : | ||
<pre> | <pre> | ||
# systemctl list-units --type=mount --state=active | # systemctl list-units --type=mount --state=active | ||
| + | </pre> | ||
| + | == A distance == | ||
| + | Toutes les commandes qui figure ici peuvent être exécutées à distance en ajoutant le paramètre ''-H @ip_machine''. | ||
| + | |||
| + | Par exemple, pour vérifier le status du démon ''httpd'' sur l'hôte 192.168.1.1 : | ||
| + | <pre> | ||
| + | # systemctl -H 127.0.0.1 status httpd | ||
</pre> | </pre> | ||
== Configuration des unités == | == Configuration des unités == | ||
| Ligne 204 : | Ligne 211 : | ||
|- | |- | ||
||5 | ||5 | ||
| − | || | + | ||runlevel5.target, graphical.target |
||Démarrage du système en mode graphique | ||Démarrage du système en mode graphique | ||
|- | |- | ||
||6 | ||6 | ||
| − | || | + | ||runlevel6.target, reboot.target |
||Redémarrage du système | ||Redémarrage du système | ||
|} | |} | ||
| Ligne 222 : | Ligne 229 : | ||
lrwxrwxrwx. 1 root root 13 26 déc. 20:23 /usr/lib/systemd/system/runlevel6.target -> reboot.target | lrwxrwxrwx. 1 root root 13 26 déc. 20:23 /usr/lib/systemd/system/runlevel6.target -> reboot.target | ||
</pre> | </pre> | ||
| + | |||
===Cible courante=== | ===Cible courante=== | ||
Pour voir la ''target'' courante ou anciennement la commande ''runlevel'' : | Pour voir la ''target'' courante ou anciennement la commande ''runlevel'' : | ||
| Ligne 316 : | Ligne 324 : | ||
Par exemple, si votre point de montage est ''/opt/sdb'' le fichier '''doit''' s'appeler ''opt-sdb.mount'' ! | Par exemple, si votre point de montage est ''/opt/sdb'' le fichier '''doit''' s'appeler ''opt-sdb.mount'' ! | ||
| + | |} | ||
| + | = Journalisation = | ||
| + | Il est possible d'afficher les logs grâce à la commande ''journalctl''. | ||
| + | {|class="wikitable" width="85%" | ||
| + | ! Description !! Commande ''journalctl'' | ||
| + | |- | ||
| + | ||Affichage de tous les logs | ||
| + | || | ||
| + | <pre> | ||
| + | # journalctl | ||
| + | </pre> | ||
| + | |- | ||
| + | ||Affichage des logs d'un démon | ||
| + | || | ||
| + | <pre> | ||
| + | # journalctl -u $daemon.service | ||
| + | </pre> | ||
| + | |- | ||
| + | ||Suivi des logs | ||
| + | || | ||
| + | <pre> | ||
| + | # journalctl -f | ||
| + | </pre> | ||
| + | |- | ||
| + | ||Affichage des logs du kernel uniquement | ||
| + | || | ||
| + | <pre> | ||
| + | # journalctl -k | ||
| + | </pre> | ||
|} | |} | ||
Version actuelle datée du 17 mai 2024 à 23:57
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
A distance
Toutes les commandes qui figure ici peuvent être exécutées à distance en ajoutant le paramètre -H @ip_machine.
Par exemple, pour vérifier le status du démon httpd sur l'hôte 192.168.1.1 :
# systemctl -H 127.0.0.1 status httpd
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é
|
# 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 | runlevel5.target, graphical.target | Démarrage du système en mode graphique |
| 6 | runlevel6.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 ! |
Journalisation
Il est possible d'afficher les logs grâce à la commande journalctl.
| Description | Commande journalctl |
|---|---|
| Affichage de tous les logs |
# journalctl |
| Affichage des logs d'un démon |
# journalctl -u $daemon.service |
| Suivi des logs |
# journalctl -f |
| Affichage des logs du kernel uniquement |
# journalctl -k |