Red Hat Training

A Red Hat training course is available for Red Hat Linux

Chapitre 9. Gérer les services avec systemd

9.1. Introduction à systemd

Systemd est un gestionnaire de systèmes et de services pour les systèmes d'exploitation Linux. Il est conçu pour être rétro-compatible avec les scripts SysV init, et fournit un certain nombre de fonctionnalités, comme le lancement en parallèle des services système pendant l'initialisation, l'activation des démons à la demande, la prise en charge des instantanés d'état du système, ou la logique de contrôle de service basée sur dépendances. Sur Red Hat Enterprise Linux 7, systemd remplace Upstart comme système init par défaut.
Systemd introduit le concept d'unités systemd (« systemd units »). Ces unités sont représentées par les fichiers de configuration d'unités dans l'un de répertoires qui se trouve dans Tableau 9.2, « Emplacements des fichiers d'unités systemd », et inclut des informations sur les services système, les sockets d'écoute, les instantanés d'état de système enregistré, et d'autres objets pertinents au système init. Pour obtenir la liste complète des types d'unité systemd disponibles, veuillez consulter Tableau 9.1, « Types d'unités systemd disponibles ».

Tableau 9.1. Types d'unités systemd disponibles

Type d'unitéExtension de fichierDescription
Unité du service.serviceService système.
Unité cible.targetUn groupe d'unités systemd.
Unité Automount.automountUn point Automount du système de fichiers.
Unité du périphérique.deviceFichier du périphérique reconnu par le noyau.
Unité de montage.mountPoint de montage du système de fichiers.
Unité de chemin.pathUn fichier ou répertoire dans un système de fichiers.
Unité scope.scopeUn processus créé de manière externe.
Unité de tranche.sliceUn groupe d'unités organisées de manière hiérarchique qui gèrent des processus système.
Unité d'instantané.snapshotUn état enregistré du gestionnaire systemd.
Unité de socket.socketUn socket de communication inter-processus.
Unité swap.swapUn périphérique ou fichier swap.
Unité minuteur.timerUn minuteur systemd.

Tableau 9.2. Emplacements des fichiers d'unités systemd

RépertoireDescription
/usr/lib/systemd/system/Fichiers d'unités systemd distribuées avec des paquets RPM installés.
/run/systemd/system/Les fichiers d'unités systemd créées pendant l'exécution. Ce répertoire a priorité sur le répertoire de fichiers d'unités de service installées.
/etc/systemd/system/Les fichiers d'unités systemd créées par systemctl enable ainsi que les fichiers d'unités ajoutés pour étendre un service. Ce répertoire a priorité sur le répertoire de fichiers d'unités de service installées.

9.1.1. Fonctionnalités principales

Sur Red Hat Enterprise Linux 7, le gestionnaire de systèmes et services systemd fournit les fonctionnalités principales suivantes :
  • Activation basée socket — pendant l'initialisation, systemd crée des sockets d'écoute pour tous les services système qui prennent en charge ce type d'activation, et passe les sockets à ces services dès qu'ils sont lancés. Ceci permet à systemd de lancer les services en parallèle, mais rend également possible le redémarrage d'un service sans perdre de message qui lui aurait été envoyé pendant son indisponibilité : le socket correspondant reste accessible et tous les messages sont mis en file d'attente.
    Systemd utilise des unités de socket « socket units » pour une activation basée socket.
  • Activation basée sur Bus — les services système qui utilisent D-Bus pour les communications inter-processus peuvent être lancés à la demande la première fois qu'une application cliente tente de communiquer avec eux. Systemd utilise des fichiers de service « D-Bus service files » pour une activation basée bus.
  • Activation basée périphérique — les services système qui prennent en charge l'activation basée périphérique peuvent être lancés à la demande lorsqu'un type particulier de matériel physique est branché ou devient disponible. Systemd utilise des unités de périphérique « device units » pour l'activation basée périphérique.
  • Activation basée chemin — les services système qui prennent en charge l'activation basée chemin peuvent être lancés à la demande lorsqu'un fichier ou répertoire particulier change d'état. Systemd utilise les unités de chemin « path units » pour l'activation basée chemin.
  • Instantanés d'état système — Systemd peut temporairement enregistrer l'état actuel de toutes les unités ou restaurer un état précédent du système à partir d'un instantané créé dynamiquement. Pour stocker l'état actuel du système, systemd utilise des unités d'instantané « snapshot units » créées dynamiquement.
  • Gestion des points de montage et des points Automount — Systemd surveille et gère tous les points de montage et d'Automount. Systemd utilise « mount units » pour les points de montage et « automount units » pour les points d'Automount.
  • Parallélisation aggressive — à cause de l'activation basée socket, systemd peut lancer des services système en parallèle une fois que tous les sockets d'écoute sont en place. Lorsque combinés aux services système qui prennent en charge l'activation à la demande, l'activation en parallèle réduit largement le temps qu'il faut pour démarrer le système.
  • Logique d'activation d'unité transactionnelle — avant d'activer ou de désactiver une unité, systemd calcule ses dépendances, crée une transaction temporaire, et vérifie que celle-ci soit bien cohérente. Si une transaction est incohérente, systemd tente automatiquement de la corriger et d'en supprimer les tâches non essentielles avant de rapporter une erreur.
  • Rétro-compatibilité avec SysV init — Systemd prend en charge les scripts SysV init comme décrit dans la spécification « Linux Standard Base Core Specification », ce qui facilite le chemin de mise à niveau des unités de service Systemd.

9.1.2. Changements de compatibilité

Le gestionnaire de systèmes et Systemd sont conçus pour être principalement compatibles avec SysV init et Upstart. Ci-dessous figurent les principaux changements de compatibilité par rapport à la dernière version majeure du système Red Hat Enterprise Linux :
  • Systemd n'offre qu'une prise en charge limitée des niveaux d'exécution. Il fournit un certain nombre d'unités cibles pouvant être directement mappées à ces niveaux d'exécution et est également distribué avec l'ancienne commande runlevel pour des raisons de compatibilité. Les cibles Systemd ne peuvent pas toutes être directement mappées aux niveaux d'exécution. Par conséquent, cette commande peut retourner N, pour indiquer un niveau d'exécution inconnu. Il est recommandé d'éviter d'utiliser la commande runlevel si possible.
    Pour obtenir davantage d'informations sur les cibles Systemd et leurs comparaisons aux niveaux d'exécution, veuillez consulter la Section 9.3, « Travailler avec des cibles Systemd ».
  • L'utilitaire systemctl ne prend pas en charge les commandes personnalisées. En plus des commandes standards, comme start, stop, et status, les auteurs de scripts SysV init peuvent implémenter un nombre de commandes arbitraires afin de fournir des fonctionnalités supplémentaires. Par exemple, le script init d'iptables sur Red Hat Enterprise Linux 6 peut être exécuté avec la commande panic, qui active immédiatement le mode de panique et reconfigure le système pour ne plus recevoir de paquets entrants et ne plus pouvoir envoyer de paquets sortants. Ceci n'est pas pris en charge sur Systemd et systemctl n'accepte que les commandes documentées.
    Pour obtenir davantage d'informations sur l'utilitaire systemctl et sa comparaison avec l'ancien utilitaire service, veuillez consulter la Section 9.2, « Gérer les services système ».
  • L'utilitaire systemctl ne communique pas avec les services qui n'ont pas été lancés par Systemd. Lorsque Systemd lance un service système, il stocket l'ID de son processus principal afin d'en garder la trace. L'utilitaire systemctl utilise ensuite ce PID pour effectuer des requêtes et pour gérer le service. Par conséquent, si un utilisateur lance un démon particulier directement sur la ligne de commande, systemctl sera incapable de déterminer son statut actuel ou de l'arrêter.
  • Systemd arrête uniquement les services en cours d'exécution. Précédemment, lorsque la séquence de fermeture était initiée, Red Hat Enterprise Linux 6 et les versions plus anciennes du système utilisaient des liens symboliques situés dans le répertoire /etc/rc0.d/ pour arrêter tous les services systèmes, quel que soit leur statut. Avec Systemd, seuls les services en cours d'exécution sont arrêtés pendant la fermeture.
  • Les services système sont incapables de lire le flux d'entrées standard. Lorsque Systemd lance un service, il connecte son entrée standard sur /dev/null pour empêcher toute interaction avec l'utilisateur.
  • Les services système n'héritent d'aucun contexte (comme les variables d'environnement HOME et PATH) provenant de l'utilisateur les invoquant et de sa session. Chaque service est exécuté dans un contexte d'exécution épuré.
  • Lors du chargement d'un script SysV init, systemd lit les informations de dépendance codées dans l'en-tête LSB (« Linux Standard Base ») et les interprète pendant l'exécution.
  • Toutes les opérations sur les unités de service sont sujettes à un délai par défaut de 5 minutes pour empêcher à tout service malfonctionnant de geler le système. Cette valeur est codée en dur pour les services générés à partir d’initscripts et ne peut pas être modifiée. Toutefois, des fichiers de configuration individuels peuvent servir à spécifier une valeur de délai d’attente plus longue pour chaque service individuel, voir Exemple 9.21, « Modifier la limite du délai d'attente »
Pour obtenir une liste détaillée des changements de compatibilité apportés avec systemd, veuillez consulter le Guide de planification de migration de Red Hat Enterprise Linux 7.