Mon réseau d’entreprise
14.2 Systemd
Le démon Systemd permet de lancer les services au démarrage, mais pas seulement. Avant, c’était le processus init qui utilisait le fichier inittab. Le fichier /sbin/init est maintenant un lien vers le nouveau systemd.
Ce démon gère les services au démarrage de l’ordinateur et leur vie ultérieure. Il fournit d’autres services : système de journalisation (log), compatible avec syslog ; l’activation régulière de commandes, en remplacement de cron ; le montage et automontage de systèmes de fichier, en complément (remplacement ?) de /etc/fstab ;
La documentation de référence est https://systemd.io/. La configuration se fait avec un myriade de fichiers de configuration au format XDG.
14.2.1 Les commandes de Systemd
14.2.1.1 Contrôler le système : systemctl
La première commande à utiliser est systemctl.
Pour vérifier l’état d’un système complet :
# systemctl status
� joe
State: running
Units: 315 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Si systemd détecte un problème, alors la commande l’affichera :
� joe
State: degraded
Units: 316 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 1 units
Le détail se verra avec l’option failed :
# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION � openipmi.service loaded failed failed LSB: OpenIPMI Driver init script
Ici, nous avons installé le paquet openipmi sur un système ne disposant pas du composant spécifique aux serveurs. En vérifiant le statut de ce paquet nous pourrons (éventuellement) obtenir la raison :
systemctl status openipmi
× openipmi.service - LSB: OpenIPMI Driver init script
Loaded: loaded (/etc/init.d/openipmi; generated)
Active: failed (Result: exit-code) since Wed 2024-08-21 09:29:59 CEST; 8min ago
Docs: man:systemd-sysv-generator(8)
Process: 744 ExecStart=/etc/init.d/openipmi start (code=exited, status=1/FAILURE)
CPU: 63ms
août 21 09:29:59 joe systemd[1]: Starting openipmi.service - LSB: OpenIPMI Driver init script...
août 21 09:29:59 joe openipmi[744]: Starting ipmi drivers ipmi failed!
août 21 09:29:59 joe openipmi[744]: .
août 21 09:29:59 joe systemd[1]: openipmi.service: Control process exited, code=exited, status=1/FAILURE
août 21 09:29:59 joe systemd[1]: openipmi.service: Failed with result 'exit-code'.
août 21 09:29:59 joe systemd[1]: Failed to start openipmi.service - LSB: OpenIPMI Driver init script.
Il confirme bien l’absence du matériel. Évidement les erreurs prévues sont plus faciles à interpréter et corriger. Pour aller plus loin dans la détection et la correction d’erreur, il est utile de consulter je journal ( ??).
14.2.1.2 Lisez le journal : journalctl
Après une pédiode de cohabitation, le vénérable syslog a disparu de la distribution Debian. Il est encore possible de le réactiver en ajoutant le paquet rsyslogd. Le fichier de log apparaît alors.
La commande journalctl permet d’explorer les journaux. Si le nombre de lignes affichées est supérieur au nombre de lignes du terminal, alors il utilise un pager (similaire à less) qui permet de naviguer dans le texte produit. Les premières options sont :
- -e
-
affiche directement la fin de la sortie ;
- -x
-
(catalog) ajoute un commentaire sur l’affichage ;
- -u UNIT
-
affiche uniquement les logs de cette unité ;
- -f
-
(follow) affiche les dernières lignes puis les nouveaux messages.
Ainsi la commande :
journalctl -eu isc-dhcp-server.service -f
permet de suivre les logs du service DHCP.
14.2.2 La configuration de systemd
La documentation d’Archlinux [https ://wiki.archlinux.org/title/Systemd] (voire la version française) est une bonne source d’information. Les fichiers de configuration sont des fichiers texte, donc facilement administrables. Il y a des fichiers disponibles dans le répertoire /usr et des activés dans le répertoire /etc. L’activation consiste à faire un lien symbolique du premier vers le second. Les services utilisateurs sont aussi pris en charge. Il y a une nouvelle notion, celle de siège (seat). Sur un système GNU/Linux, il est possible d’avoir plusieurs sessions console ou graphique. En utilisant les racourcis CTRL-ALT-F (i variant de 1 à 6 ou plus) ou la commande chvt, il est aisé de changer de session. La notion de siège indique la session active pour favoriser l’utilisateur assis devant l’écran. Il aura ainsi l’usage de la carte son.
systemctl list-unit-files --type service container-getty@.service static - cron.service enabled enabled cryptdisks-early.service masked enabled
systemctl daemon-reload
If you want a service to be launched at startup you must enable it :
systemctl enable htg
Enabling a service doesn’t start it, it only sets it to be launched at boot time. To start the service now, you must use systemctl with the start option.
systemctl start htg
14.2.3 Gérer un service
Le répertoire pour ajouter la définition d’un service est /etc/systemd/system/. Les fichiers définissent des unités (unit). Ces unités peuvent être :
- service
-
la gestion d’un service ou d’une application ;
- timer
-
activation régulière d’un service ;
- mount
-
un point de montage ;
- automount
-
un montage automatique, dépend d’un fichier mount.
D’autres types existent mais ne seront pas décrits ici.
Le fichier décrivant un service est divisé en trois sections : Unit, Service et Install. D’autres existent pour d’autres types d’unité (mount, timer…).
14.2.3.1 La section Unit
Cette section est la premère. Elle permet de définir des méta-données et les relations avec d’autres unités. Les directives sont :
- Description
- Documentation
- Requires
-
liste les unités qui doivent être fonctionnelles avant de lancer cette unité.
- Wants
-
liste les unités qui doivent être lancées avant le lancement de cette unité. Contrairement à Requires, si les dépendances échouent, l’unité est quand même lancée.
- Before
- After
-
14.2.3.2 La section Install
Cette section est la dernière. Elle décrit le comportement si l’unité est activée (enabled). Par conséquence, seules les unités activables peuvent avoir cette section.
- WantedBy
- RequiredBy
-
14.2.3.3 La directive Service
Cette directive définit le comportement du service, en particulier le lancement et l’arrêt.
Type: Simple. systemd will consider this service started as soon as the process specified by ExecStart has been forked. ExecStart: The path to the process that should be started. Restart: When and if the service should be restarted. We have set it to "on-failure." RestartSec: How long to wait before attempting to restart the service. This value is in seconds. KillMode: Defines how systemd should kill the process if we ask systemctl to stop the service. We have this set to "process." This causes systemd to use the SIGTERM signal on the main process only. If our service was a non-trivial program instead of a simple script, we would set this to "mixed" to ensure that any spawned processes were also ter
[Unit] Description=RTL-SDR Wants=network.target After=syslog.target network-online.target [Service] Type=simple ExecStart=/usr/bin/rtl_433 -R 131 -R 85 -F "mqtt://localhost 1883 user mqttuser pass x retain 0 devices rtl_433[/id]" Restart=on-failure RestartSec=10 KillMode=process [Install] WantedBy=multi-user.target
14.2.4 Références
https://blog.stefan-koch.name, https://blog.stefan-koch.name/2020/12/10/qemu-guest-graceful-shutdown-from-python