Différences entre versions de « Systemctl »

De The Linux Craftsman
Aller à la navigation Aller à la recherche
 
(10 versions intermédiaires par le même utilisateur non affichées)
Ligne 57 : Ligne 57 :
 
|-
 
|-
 
||chkconfig $daemon
 
||chkconfig $daemon
−
||systemctl is-enable $daemon.service
+
||systemctl is-enabled $daemon.service
 
||Permet de voir si $daemon est actif au démarrage du système
 
||Permet de voir si $daemon est actif au démarrage du système
 
|-
 
|-
 
||chkconfig $daemon --list
 
||chkconfig $daemon --list
−
||systemctl is-enable $daemon.service
+
||systemctl list-units --type=service --all
−
||Permet de voir si $daemon est actif au démarrage du système
+
||Permet de voir la liste des services et s'ils sont actifs ou non au démarrage du système
 
|-
 
|-
 
|align="center"|X
 
|align="center"|X
Ligne 73 : Ligne 73 :
 
|}
 
|}
 
Il est possible de ne pas ajouter le ''.service'', ''systemctl'' comprendra très bien qu'il s'agit d'un service !
 
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'' !
+
Nous allons maintenant passer en revue les unités que nous pouvons manipuler avec systemctl !
−
== Gestion des unités ==
+
 
−
=== État des unités ===
+
= Gestion des unités =
 +
== État des unités ==
 
''systemctl'' peut afficher des informations sur les unités :
 
''systemctl'' peut afficher des informations sur les unités :
 
<pre>
 
<pre>
Ligne 97 : Ligne 98 :
 
# systemctl list-units --type=mount --state=active
 
# systemctl list-units --type=mount --state=active
 
</pre>
 
</pre>
−
=== Configuration des unités ===
+
== 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>
 +
== Configuration des unités ==
 
{|class="wikitable" width="85%"
 
{|class="wikitable" width="85%"
 
|-
 
|-
Ligne 172 : Ligne 180 :
 
|}
 
|}
  
−
=== Les cibles ===
+
== Les cibles ==
 +
===Aperçu===
 +
Les cibles reprennent le concept des [[Gestionnaire_de_démarrage#runlevel.2C_kesako_.3F|''runlevel'']] de SysVInit :
 +
<pre>
 +
# 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
 +
</pre>
  
−
== Gestion des disques ==
+
On voit qu'il y en a 6 et voici leur utilité :
 +
{|class="wikitable" width="85%"
 +
!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'' :
 +
<pre>
 +
# 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
 +
</pre>
 +
 
 +
===Cible courante===
 +
Pour voir la ''target'' courante ou anciennement la commande ''runlevel'' :
 +
<pre>
 +
# systemctl get-default
 +
multi-user.target
 +
# runlevel
 +
N 3
 +
</pre>
 +
===Changement de cible===
 +
Enfin, on peut changer la ''target'' courante grâce à l'option ''isolate'' :
 +
<pre>
 +
# systemctl isolate graphical.target
 +
</pre>
 +
Quand l'option ''isolate'' est utilisée, le suffixe ''.target'' n'est pas obligatoire.
 +
 
 +
Certaine target on des racourcis :
 +
*
 +
<pre>
 +
# systemctl isolate poweroff.target
 +
</pre>
 +
équivaut à
 +
<pre>
 +
# poweroff
 +
</pre>
 +
*
 +
<pre>
 +
# systemctl isolate reboot.target
 +
</pre>
 +
équivaut à
 +
<pre>
 +
# reboot
 +
</pre>
 +
===Changer la cible par défaut===
 +
La cible par défaut se trouve dans le répertoire ''/etc/systemd/system'' :
 +
<pre>
 +
# 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
 +
</pre>
 +
Il suffit de remplacer le lien symbolique pour modifier la cible par défaut !
 +
<pre>
 +
# ln -fs /lib/systemd/system/graphical.target /etc/systemd/system/default.target
 +
</pre>
 +
Ou, plus simple, on peut utiliser l'option ''set-default'' :
 +
<pre>
 +
# 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.
 +
</pre>
 +
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.
 
''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é [[Gestion_des_disques#Cr.C3.A9ation_d.27une_partition |partitionné]] et [[Gestion_des_disques#Formatage|formaté]], il ne reste plus qu'à le monter. Traditionnellement nous aurions utilisé la commande [[Gestion_des_disques#mount | ''mount'']] et modifié le fichier [[Gestion_des_disques#fstab |''/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/'' :
+
Dans cet exemple, le disque ''sdb'' à déjà été [[Gestion_des_disques#Cr.C3.A9ation_d.27une_partition |partitionné]] et [[Gestion_des_disques#Formatage|formaté]], il ne reste plus qu'à le monter. Traditionnellement nous aurions utilisé la commande [[Gestion_des_disques#mount | ''mount'']] et modifié le fichier [[Gestion_des_disques#fstab |''/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/'' :
 
<pre>
 
<pre>
 
[Unit]
 
[Unit]
Ligne 216 : 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 :

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-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é



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 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
Warning manual.jpg

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
Récupérée de « https://tala-informatique.fr/index.php?title=Systemctl&oldid=4030 »