Remarque :

Utilisation de systemd sur Oracle Linux

Introduction

Dans ce tutoriel, vous allez apprendre à utiliser l'utilitaire de ligne de commande systemctl pour gérer et afficher les unités systemd contrôlées par systemd. Ce tutoriel s'adresse aux utilisateurs d'Oracle Linux 8 ou version ultérieure.

systemd est le premier processus qui démarre à l'initialisation et est le dernier processus à s'arrêter à l'arrêt du système. systemd est principalement utilisé pour gérer les services ou les processus système et l'initialisation du système à l'initialisation. Toutefois, systemd est également capable de gérer de nombreuses autres tâches et fonctions, notamment la journalisation des événements, la gestion des périphériques, la connexion utilisateur, la planification des tâches, la synchronisation de l'heure et l'initialisation du système. De nombreuses fonctionnalités dans systemd ne sont pas entièrement utilisées car les utilisateurs peuvent être plus à l'aise avec les autres logiciels à ces fins ou des distributions Linux différentes peuvent avoir des approches préférées pour la configuration du système.

Différents types de comportement ou fonctions au sein de systemd sont gérés en unités systemd. Par exemple, les processus du démon ou les services système sont exécutés en tant qu'unités de service, tandis que les états du système sont généralement définis en tant qu'unités cible. Vous pouvez définir des unités d'horloge pour planifier des tâches de la même manière que vous pouvez utiliser le service cron système et utiliser une unité de montage pour configurer un point de montage de la même manière que vous pouvez configurer un point de montage dans le fstab système.

systemd est utilisé pour gérer les processus et les fonctions au niveau du système, mais il est également capable de gérer les processus s'exécutant dans l'espace utilisateur. Les utilisateurs d'un système peuvent configurer et gérer leurs propres services et systemd peut même être configuré pour permettre à ces services de continuer à s'exécuter une fois que l'utilisateur a interrompu sa session.

Objectifs

De quoi avez-vous besoin ?

Remarque : lorsque vous utilisez l'environnement d'exercices gratuits, reportez-vous à Notions de base d'Oracle Linux Lab pour obtenir des instructions de connexion et d'utilisation.

Explorer les fichiers d'unité systemd

Une fois connecté à l'instance Oracle Linux 8, vous pouvez commencer à expérimenter la commande systemctl pour connaître les différentes unités disponibles.

  1. Exécutez la commande systemctl pour répertorier toutes les unités systemd actuellement chargées par systemd :

    systemctl
    

    Utilisez l'espace ou les touches PgDn du clavier pour parcourir la sortie.

    Cette commande équivaut à exécuter :

    systemctl list-units
    

    La sortie affiche toutes les unités de configuration actuellement actives gérées par systemd. Dans la sortie, vous devez remarquer qu'il existe des unités nommées avec différents suffixes, y compris des unités nommées avec les suffixes '.device', '.mount','.service', '.target' et '.timer'.

    Les unités sont actives dans le sens où elles sont démarrées, en cours d'exécution, montées ou connectées, selon leur fonction. Les unités peuvent être inactives au sens où elles sont arrêtées, démontées ou déconnectées. Si vous souhaitez voir toutes les unités, qu'elles soient actives ou non, vous pouvez exécuter :

    systemctl list-units --all
    

    La sortie de ces commandes montre une sélection des différents types d'unités systemd :

    • automount : fournit des fonctionnalités de montage automatique pour le montage à la demande des systèmes de fichiers et le démarrage en parallèle.
    • mount : contrôle les points de montage dans les affichages de date et d'heure actuels du système de fichiers.
    • path : permet d'activer les services lorsque les informations de chemin du système de fichiers sont modifiées.
    • scope : similaire aux unités de service, mais gère les processus étrangers au lieu de les démarrer.
    • service : démarre et contrôle les démons et les processus qu'ils composent.
    • slice : permet de regrouper les unités qui gèrent les processus système, telles que les unités de service et les unités de portée, dans l'arborescence Cgroup hiérarchique à des fins de gestion des ressources.
    • socket : encapsule dans le système des sockets de réseau ou de communication interprocessus locale, utiles pour l'activation basée sur le socket.
    • target : permet de regrouper des unités ou de fournir des points de synchronisation bien connus lors de l'initialisation.
    • timer : permet de déclencher l'activation d'autres unités à l'aide d'horloges. Elles constituent une alternative aux tâches qui ont pu être précédemment gérées à l'aide du service cron.
    • device : présente les périphériques de noyau dans systemd et peut également être utilisé pour implémenter l'activation basée sur les périphériques.
    • swap : encapsule des partitions de swap de mémoire ou des fichiers de swap.
  2. Limitez la liste des unités à un type d'unité particulier à l'aide de l'option --type.

    • Utilisez la commande systemctl list-units --type services pour répertorier les unités de service actuellement actives sur votre système.

      systemctl list-units --type service
      
    • Exécutez à nouveau la même commande, mais incluez l'option --all pour afficher toutes les unités chargées, y compris celles qui sont inactives, le cas échéant.

      systemctl list-units --type service --all
      

Vous pouvez répéter ces commandes pour chacun des types de service disponibles, afin de limiter les informations au type qui vous intéresse à tout moment.

Utiliser les unités cible systemd

Les unités cible sont utilisées pour regrouper différentes unités afin de placer le système dans un état particulier afin qu'il soit prêt à fonctionner dans un but particulier.

  1. Répertoriez les unités target disponibles.

    systemctl list-units --type target
    

    Les unités peuvent nécessiter le chargement d'autres unités ou être configurées pour entrer en conflit avec des unités particulières. Par exemple, multi-user.target requiert que basic.target fonctionne et qu'il soit également en conflit avec les unités rescue.service et rescue.target. Les unités indiquent également les autres unités qu'elles souhaitent charger pour pouvoir fonctionner.

    De cette façon, les cibles peuvent être enchaînées pour configurer un état particulier, mais elles sont également suffisamment modulaires pour être réutilisées pour déclencher un autre état.

  2. Affichez l'unité cible par défaut.

    L'unité cible par défaut définit l'état du système par défaut après l'initialisation.

    • Utilisez la commande systemctl get-default pour visualiser l'unité cible utilisée par défaut. L'unité cible par défaut est représentée par le fichier /etc/systemd/system/default.target.

      systemctl get-default
      
    • Utilisez la commande ls -l pour répertorier les informations sur le fichier /etc/systemd/system/default.target.

      ls -l /etc/systemd/system/default.target
      

      Remarque : le fichier default.target est un lien symbolique vers le fichier d'unité cible par défaut actuel.

  3. Modifiez l'unité cible par défaut.

    • Utilisez la commande systemctl set-default pour remplacer l'unité cible par défaut par l'unité graphical.target.

      systemctl set-default graphical.target
      
    • Utilisez la commande ls –l pour confirmer que le fichier default.target est désormais un lien symbolique vers le fichier graphical.target.

      ls -l /etc/systemd/system/default.target
      

      Remarque : la modification de l'unité cible par défaut enlève le lien symbolique default.target existant et recrée le lien symbolique, qui pointe vers la nouvelle unité cible par défaut.

  4. Pour plus d'informations, explorez une cible.

    • Utilisez la commande systemctl show pour obtenir plus d'informations sur une cible spécifique.

      systemctl show multi-user.target
      

      La sortie affiche tous les paramètres de la cible que vous indiquez. Notez que vous pouvez identifier les unités requises, souhaitées et en conflit avec la cible, ainsi que les unités devant être exécutées avant et après cette cible.

    • Utilisez la commande systemctl list-dependencies pour afficher l'arborescence des dépendances requises ou souhaitées pour qu'une cible particulière atteigne son état :

      systemctl list-dependencies default.target
      

      Cette commande affiche toutes les unités démarrées lorsque vous démarrez la cible par défaut. La chaîne d'unités est présentée de manière récursive dans un arbre qui permet d'évaluer pleinement ce que la cible atteint au démarrage. Si vous avez défini graphical.target comme cible par défaut, vous pouvez constater que le système souhaite exécuter display-manager.service pour charger l'affichage graphique, mais il exécute également multi-user.target pour effectuer toutes les opérations requises avant d'exécuter l'affichage graphique.

Utilisation de systemctl pour activer, désactiver et masquer des unités

Les unités peuvent être désactivées ou activées et peuvent également être masquées pour qu'elles ne s'exécutent jamais dans aucune circonstance. Certaines unités sont statiques dans la mesure où elles sont toujours disponibles, généralement parce qu'il s'agit de dépendances pour que d'autres unités fonctionnent. La commande systemctl list-units peut uniquement être utilisée pour afficher les unités actives ou inactives sur le système.

  1. Répertoriez toutes les unités disponibles sur le système, ainsi que leur état :

    systemctl list-unit-files
    

    La plupart des unités disponibles sont statiques. Les unités activées démarrent à l'initialisation. Les unités désactivées sont des unités disponibles sur le système mais qui ne sont pas configurées pour démarrer à l'initialisation. Les unités masquées sont disponibles sur le système mais ont été activement définies sur un état dans lequel elles ne peuvent pas être démarrées.

  2. Utilisez la commande systemctl status pour afficher des informations détaillées sur l'unité nfs-server.service.

    systemctl status nfs-server.service
    

    La commande systemctl permet de supprimer l'extension .service lorsque vous faites référence à des unités de service.

    La commande status indique si une unité est activée, active, inactive, désactivée ou masquée.

    Pour les solutions scriptées, systemctl fournit de courtes commandes permettant de générer le statut sur une seule ligne :

    • Utilisez la commande systemctl is-active pour vérifier si le service nfs-server est en cours d'exécution (actif) ou non (inactif).

      systemctl is-active nfs-server
      
    • Utilisez la commande systemctl is-enabled pour vérifier si le service nfs-server est activé ou désactivé. Lorsque le service est activé, il démarre à la réinitialisation du système.

      systemctl is-enabled nfs-server
      
  3. Activez le démarrage d'un service à l'initialisation.

    La commande systemctl enable permet d'activer le service nfs-server.

    sudo systemctl enable --now nfs-server
    

    Vous devez exécuter la commande systemctl avec des privilèges d'administrateur si la commande change d'état ou de configuration du système. Vous pouvez utiliser l'option --now pour démarrer le service en même temps que vous l'activez.

    Remarque : la commande active le service en créant un lien symbolique pour la cible système-état de niveau inférieur à laquelle le service démarre. Dans la sortie, la commande a créé le lien symbolique nfs-server.service pour la cible multi-user.

    Utilisez systemctl status command pour vérifier que le service nfs-server est maintenant activé et en cours d'exécution.

    systemctl status nfs-server
    
  4. Désactivez et arrêtez un service.

    La commande systemctl disable permet de désactiver le service nfs-server. Notez également que la commande systemctl disable supprime le lien systemctl pour le service.

    sudo systemctl disable nfs-server
    

    Utilisez la commande systemctl stop pour arrêter le service nfs-server.

    sudo systemctl stop nfs-server
    

    Vous pouvez combiner ces étapes à l'aide de l'option --now lorsque vous désactivez le service.

  5. Masquer et démasquer une unité.

    Dans certains cas, vous pouvez désactiver le démarrage des unités. En règle générale, vous pouvez effectuer cette opération si une unité particulière est en conflit avec d'autres fonctionnalités du système ou pour une raison de stratégie.

    Utilisez la commande systemctl mask pour masquer le service nfs-server :

    sudo systemctl mask nfs-server
    

    Un lien symbolique est créé pour garantir que la configuration d'unité systemd pointe vers /dev/null. Cela empêche l'activation ou le démarrage du service.

    Vérifiez que vous ne pouvez pas démarrer l'unité de serveur NFS lorsqu'elle est masquée :

    sudo systemctl start nfs-server
    

    Le service ne peut pas démarrer et une erreur est renvoyée pour indiquer que le service est masqué.

    Ne masquez pas l'unité pour la remettre à son état d'origine et permettre aux utilisateurs de démarrer ou d'activer le service.

    sudo systemctl unmask nfs-server
    

Configurer systemd pour les unités d'espace utilisateur

En général, systemd est utilisé pour gérer les unités au niveau système. Les utilisateurs ont besoin d'un accès de niveau administrateur au système pour gérer les unités systemd ainsi configurées. Dans certains environnements et pour certains types d'unités, les utilisateurs peuvent souhaiter utiliser la capacité du système à exécuter des unités dans l'espace utilisateur. Par exemple, les utilisateurs souhaiteront peut-être planifier des tâches à l'aide des fonctionnalités d'unité de minuteur de systemd ou exécuter des applications ou des services spécifiques en tant qu'unités de service ne nécessitant pas d'autorisation d'exécution au niveau racine.

systemd démarre un processus systemd-user pour un utilisateur à la connexion. Les unités situées dans les répertoires suivants sont traitées dans l'ordre suivant pour l'utilisateur :

Vous pouvez indiquer systemd que vous travaillez dans l'espace utilisateur à l'aide de l'option --user pour n'importe quelle commande systemd.

  1. Répertoriez les fichiers d'unités actuellement disponibles pour votre utilisateur.

    systemctl --user list-unit-files
    

    La liste des unités disponibles est beaucoup plus courte que lorsque vous exécutez la même commande sans l'option --user.

    La majorité de ces fichiers d'unité, sur un nouveau système, se trouve dans /usr/lib/systemd/user. Répertoriez les fichiers de ce répertoire pour visualiser les unités situées ici :

    ls -la /usr/lib/systemd/user/
    
  2. Créez un répertoire pour héberger vos propres fichiers d'unités systemd.

    mkdir -p $HOME/.config/systemd/user
    
  3. Créez votre propre unité de service systemd.

    cat << EOF > $HOME/.config/systemd/user/uptime.service
    [Unit]
    Description="Logs system uptime and load average"
    Wants=uptime.timer
    
    [Service]
    ExecStart=/usr/bin/uptime
    
    [Install]
    WantedBy=default.target
    
    EOF
    

    Cette unité de service fournit trois sections de configuration.

    La section Unit fournit une description de l'unité et de toutes les conditions requises. Dans ce cas, une entrée Wants définit un besoin faible pour une unité d'horloge qui n'existe pas encore. Les unités répertoriées en tant qu'entrées Wants sont exécutées si elles sont disponibles mais n'empêchent pas l'exécution de l'unité parent si elles sont introuvables ou échouent.

    La section Service définit le comportement de cette unité de service spécifique lors de son exécution. Nous utilisons de nombreuses valeurs par défaut pour les options disponibles ici et indiquons uniquement la ligne ExecStart, qui spécifie la commande exécutée au démarrage du service. Dans ce cas, la commande uptime est exécutée pour consigner les valeurs de temps d'activité et de charge du système.

    La section Install définit la façon dont le service doit être installé sur le système lorsqu'il est activé. Notamment, le service est ajouté en tant que service WantedBy sur "default.target". Cela signifie que le service est activé dans le cadre de la cible par défaut pour cet utilisateur.

  4. Exécutez l'unité systemd et vérifiez sa sortie.

    Etant donné que vous avez ajouté une nouvelle unité, il est généralement recommandé de recharger la configuration systemd avant de tenter d'exécuter le service :

    systemctl --user daemon-reload
    

    Démarrez maintenant la nouvelle unité.

    systemctl --user start uptime
    

    Vérifiez que la commande a été exécutée comme prévu. Vous pouvez vérifier que le service a été exécuté en vérifiant son statut :

    systemctl --user status uptime
    

    Remarque : ces commandes utilisent l'option --user pour s'exécuter dans l'espace utilisateur.

    Pour vérifier la sortie de la commande uptime exécutée, utilisez la commande journalctl afin d'afficher le journal et de spécifier l'option de balise afin d'afficher les journaux propres à la commande :

    journalctl -t uptime
    

    Vous pouvez activer ce service pour qu'il démarre lorsque votre utilisateur se connecte pour la première fois au système.

    systemctl --user enable uptime
    

    Notez que le service s'exécute lorsque l'utilisateur se connecte pour la première fois au système. Il ne démarre pas automatiquement à l'initialisation du système. En général, les services exécutés dans l'espace utilisateur prennent fin une fois que l'utilisateur se déconnecte ou que toutes les sessions utilisateur sont interrompues. L'activation de la persistance pour les services utilisateur est traitée plus loin dans ce tutoriel.

Utiliser les unités de temps systemd

Dans cet exercice, vous allez vous appuyer sur l'exercice précédent pour créer et permettre à une unité de minuterie d'exécuter régulièrement une autre unité systemd à un moment ou un intervalle donné. Les unités d'horloge peuvent être définies au niveau du système et au niveau de l'utilisateur et peuvent être utilisées pour définir quand systemd doit exécuter une autre unité. Les unités d'horloge fournissent un contrôle granulaire sur les événements planifiés et peuvent servir d'alternative à l'utilisation du démon cron pour gérer des configurations plus subtiles.

De nombreux services système incluent des unités d'horloge pour contrôler leur exécution. Un bon exemple d'unité d'horloge est inclus dans le package dnf-automatic qui peut être utilisé pour maintenir votre système à jour lorsqu'il effectue automatiquement des mises à jour dnf régulières. Pour le voir en action au niveau du système, installez le package et activez l'unité de minuteur :

sudo dnf install -y dnf-automatic
sudo systemctl enable dnf-automatic.timer

Vous pouvez afficher le fichier d'unités pour voir comment cette unité est configurée :

cat /usr/lib/systemd/system/dnf-automatic.timer

Contenu notable dans cette unité, incluez une ligne Wants qui attend que network-online.target soit atteint. L'entrée OnCalendar dans la section Timer de la configuration suggère que cette action est exécutée quotidiennement sur 06h00. L'entrée RandomizedDelaySec est également intéressante, ce qui peut aider à empêcher les unités d'horloge de se déclencher exactement en même temps et à pousser soudain la charge du système.

L'exemple fourni ici fait partie d'un ensemble d'unités beaucoup plus complexe. Pour mieux comprendre le fonctionnement des unités de minuteur, ajoutez une unité de minuteur dans l'espace utilisateur afin de programmer l'élément uptime.service que vous avez créé dans l'exercice précédent afin qu'il s'exécute à intervalles réguliers.

  1. Créez un fichier d'unité de minuteur.

    cat <<EOF > $HOME/.config/systemd/user/uptime.timer
    [Unit]
    Description=Timer for the uptime service that logs uptime
    Requires=uptime.service
    
    [Timer]
    Unit=uptime.service
    OnCalendar=*-*-* *:*:00
    
    [Install]
    WantedBy=timers.target
    

    Ce fichier indique que uptime.service est requis pour l'exécution de cette unité d'horloge. Cette exigence est beaucoup plus forte que tout ce qui est défini dans une définition Wants et l'unité ne s'exécute pas si la condition n'est pas satisfaite.

    La section Timer définit qu'elle charge l'unité uptime.service à l'aide d'une entrée OnCalendar. L'entrée OnCalendar fonctionne de la même manière que les options d'une définition crontab, mais offre une plus grande granularité. Dans ce cas, l'unité est définie pour s'exécuter toutes les minutes à 00 secondes.

  2. Etant donné que vous avez modifié la configuration systemd, rechargez les démons systemd et redémarrez le service de temps de disponibilité afin qu'il puisse récupérer la nouvelle unité d'horloge :

    systemctl --user daemon-reload
    systemctl --user restart uptime
    
  3. Répertoriez les unités pour vérifier que les unités uptime.service et uptime.timer sont en cours d'exécution.

    systemctl --user list-units
    
  4. Surveillez la sortie de journal dans le journal pour voir la sortie de temps d'activité déclenchée par l'exécution du service de temps d'activité toutes les minutes.

    journalctl -f -t uptime
    

    Au bout de quelques minutes, plusieurs lignes de sortie auraient dû s'afficher. Si vous accordez une attention particulière, vous remarquerez peut-être que la commande uptime ne se déclenche pas toujours exactement à la minute. Cette fonction est intentionnelle dans la fonctionnalité d'horloge systemd. Les travaux d'horloge sont déclenchés avec un randomiseur qui peut permettre le déclenchement d'une tâche avec un délai d'attente pouvant aller jusqu'à une minute. Cela permet d'empêcher les horloges de se déclencher exactement en même temps. Vous pouvez forcer une horloge à être incroyablement précise en définissant la précision sur une nanoseconde de l'événement planifié, en ajoutant l'entrée de configuration suivante à la section de l'unité d'horloge Timer :

    AccuracySec=1us
    

    Toutefois, pour la plupart des tâches, il est judicieux d'autoriser un certain degré d'inexactitude afin d'éviter une exécution trop synchrone des tâches.

    Vous pouvez utiliser la combinaison de touches Ctrl-C pour quitter le journal lorsque vous avez terminé la surveillance.

Configurer les processus d'espace utilisateur pour continuer après la déconnexion

Par défaut, les services et les processus démarrés et détenus par un utilisateur sont arrêtés lorsque l'utilisateur se déconnecte ou lorsque toutes les sessions de l'utilisateur sont terminées. Vous pouvez utiliser plusieurs méthodes pour modifier ce comportement par défaut dans systemd. Deux options sont explorées ici.

Utilisez la commande loginctl pour activer les utilisateurs systemd linger

La commande loginctl permet de modifier le comportement par défaut d'un utilisateur spécifique et d'activer les processus de cet utilisateur sur "linger" une fois la session de l'utilisateur terminée.

  1. Utilisez l'utilitaire loginctl pour activer linger pour un utilisateur spécifique. Dans cette instance, activez le comportement systemd linger pour l'utilisateur 'oracle' :

    sudo loginctl enable-linger oracle
    
  2. Pour vérifier que le paramètre est appliqué, recherchez un fichier portant le même nom que l'utilisateur dans le répertoire /var/lib/systemd/linger.

    ls /var/lib/systemd/linger/oracle
    

    La commande doit vérifier que le fichier existe.

Modifier le fichier systemd logind.conf

Systemd gère les événements de connexion utilisateur et fournit un fichier de configuration qui peut être modifié pour définir le comportement par défaut des différents événements liés à la session de l'utilisateur. Ce fichier de configuration se trouve dans /etc/systemd/logind.conf.

  1. Videz le contenu de la configuration existante à l'adresse /etc/systemd/logind.conf à l'écran pour vérifier :

    cat /etc/systemd/logind.conf
    

    La plupart des options sont commentées mais affichent les valeurs par défaut de la compilation. Il existe trois options dans ce fichier qui permettent de contrôler la façon dont systemd gère les processus en cours d'exécution dans l'espace utilisateur lorsque la session de l'utilisateur se termine.

    • KillUserProcesses : cette option peut contrôler si les processus utilisateur sont arrêtés par défaut à la fin de la session. La définition de cette option sur 'no' permet à systemd d'exécuter des processus utilisateur après la déconnexion d'un utilisateur du système.
    • KillExcludeUsers : si l'option KillUserProcesses est activée, cette option vous permet d'indiquer une liste d'utilisateurs séparés par des espaces pour lesquels systemd permet aux processus de continuer à s'exécuter une fois la session terminée. L'ajout d'un nom d'utilisateur à cette liste se comporte de la même manière que l'ajout d'un utilisateur au groupe Linger systemd à l'aide de la commande loginctl.
    • KillOnlyUsers : si l'option KillUserProcesses est désactivée, ce paramètre peut être utilisé pour indiquer une liste d'utilisateurs séparés par des espaces pour lesquels les processus doivent être arrêtés après la déconnexion.

Démonstration vidéo

Les démonstrations vidéo sur systemd sont disponibles à l'adresse https://www.youtube.com/watch?v=9uDvnZKhU8A et https://www.youtube.com/watch?v=Tkxs-wfZrnw si vous avez besoin de plus d'informations sur l'utilisation de systemd sur Oracle Linux 8.

Système systemd et gestionnaire des services sur Oracle Linux 8

Unités cible systemd sur Oracle Linux 8

Plus d'informations

Ressources de formation supplémentaires

Explorez d'autres exercices sur docs.oracle.com/learn ou accédez à davantage de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir Oracle Learning Explorer.

Pour consulter la documentation du produit, consultez le centre d'aide Oracle.