Mon réseau

Mon réseau d’entreprise

14.2 Systemd

Précédent   Suivant

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

Précédent   Suivant