Contrôle des services dans Red Hat Enterprise Linux

Introduction

Dans ce laboratoire, vous acquerrez une expérience pratique de la gestion des services système sur RHEL à l'aide de la commande systemctl. Vous apprendrez à afficher tous les services chargés et actifs, à vérifier l'état de services spécifiques et à contrôler leur comportement à l'exécution en les démarrant, les arrêtant et les redémarrant. De plus, vous explorerez comment recharger les configurations des services, activer ou désactiver des services pour un démarrage automatique au boot, et comprendrez les concepts avancés de masquage et de démasquage pour empêcher leur activation.

Ce guide pratique vous dotera des compétences essentielles en administration système, vous permettant de surveiller et de gérer efficacement le cycle de vie des services cruciaux pour le fonctionnement de votre système RHEL.

Afficher tous les services chargés et actifs avec systemctl

Dans cette étape, vous apprendrez à identifier les processus système démarrés automatiquement à l'aide de la commande systemctl. systemctl est l'outil principal pour gérer les services systemd dans Red Hat Enterprise Linux.

Tout d'abord, explorons comment lister toutes les unités de service actuellement chargées et actives. La commande systemctl list-units --type=service est utilisée à cette fin. Cette commande affiche les unités de service que le démon systemd a correctement analysées et chargées en mémoire, et qui sont actuellement actives.

Ouvrez votre terminal dans l'environnement RHEL. Vous êtes déjà connecté en tant qu'utilisateur labex et votre répertoire actuel est ~/project.

Exécutez la commande suivante pour lister toutes les unités de service chargées et actives :

systemctl list-units --type=service

Vous verrez une sortie similaire à celle-ci, affichant divers services et leurs états :

UNIT                  LOAD    ACTIVE  SUB      DESCRIPTION
atd.service           loaded  active  running  Job spooling tools
auditd.service        loaded  active  running  Security Auditing Service
chronyd.service       loaded  active  running  NTP client/server
crond.service         loaded  active  running  Command Scheduler
dbus-broker.service   loaded  active  running  D-Bus System Message Bus
...output omitted...

Analysons les colonnes de la sortie :

UNIT : Il s'agit du nom de l'unité de service, se terminant généralement par .service.
LOAD : Indique si le démon systemd a correctement analysé la configuration de l'unité et l'a chargée en mémoire. loaded signifie que l'opération a réussi.
ACTIVE : Il s'agit de l'état d'activation de haut niveau de l'unité. active signifie généralement que l'unité a démarré avec succès.
SUB : Il s'agit de l'état d'activation de bas niveau, fournissant des informations plus détaillées. Pour les services en cours d'exécution, running est courant.
DESCRIPTION : Une brève description de la fonction du service.

Appuyez sur q pour quitter la commande.

Ensuite, vous pouvez utiliser l'option --all avec systemctl list-units --type=service pour lister toutes les unités de service, quel que soit leur état d'activation (actif, inactif, en échec, etc.). Cela peut être utile pour voir les services installés mais qui ne sont pas actuellement en cours d'exécution.

Exécutez la commande suivante :

systemctl list-units --type=service --all

La sortie inclura les services qui sont inactive ou dans d'autres états, offrant une vue plus complète :

UNIT                          LOAD      ACTIVE   SUB     DESCRIPTION
  atd.service                 loaded    active   running Job spooling tools
  auditd.service              loaded    active   running Security Auditing ...
  auth-rpcgss-module.service  loaded    inactive dead    Kernel Module ...
  chronyd.service             loaded    active   running NTP client/server
  cpupower.service            loaded    inactive dead    Configure CPU power ...
  crond.service               loaded    active   running Command Scheduler
  dbus-broker.service         loaded    active   running  D-Bus System Message Bus
● display-manager.service     not-found inactive dead    display-manager.service
...output omitted...

Enfin, pour voir l'état de tous les fichiers d'unité installés, y compris ceux qui ne sont pas chargés ou actifs, vous pouvez utiliser systemctl list-unit-files --type=service. Cette commande indique si un service est enabled (démarre au boot), disabled (ne démarre pas au boot), static (ne peut pas être activé directement mais peut être démarré par une autre unité), ou masked (empêché de démarrer).

Exécutez la commande suivante :

systemctl list-unit-files --type=service

Vous verrez une sortie similaire à celle-ci, indiquant le STATE et le VENDOR PRESET pour chaque fichier d'unité de service :

UNIT FILE                         STATE       VENDOR PRESET
arp-ethers.service                disabled    disabled
atd.service                       enabled     enabled
auditd.service                    enabled     enabled
auth-rpcgss-module.service        static      -
autovt@.service                   alias       -
blk-availability.service          disabled    disabled
...output omitted...

Cette commande est particulièrement utile pour comprendre quels services sont configurés pour démarrer automatiquement au démarrage du système.

Vérifier l'état d'un service spécifique avec systemctl status

Dans cette étape, vous apprendrez à vérifier l'état détaillé d'un service spécifique à l'aide de la commande systemctl status. Cette commande fournit des informations complètes sur un service, notamment s'il est en cours d'exécution, son ID de processus (PID), son utilisation de la mémoire et les entrées de journal récentes.

Nous utiliserons crond.service (le démon cron) comme exemple. Le démon cron est un service courant qui gère les tâches planifiées.

Ouvrez votre terminal dans l'environnement RHEL. Assurez-vous d'être dans votre répertoire ~/project.

Exécutez la commande suivante pour vérifier l'état de crond.service :

systemctl status crond.service

Vous verrez une sortie détaillée similaire à celle-ci :

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Mon 2022-03-14 05:38:10 EDT; 25min ago
   Main PID: 1089 (crond)
      Tasks: 1 (limit: 35578)
     Memory: 1.2M
        CPU: 12ms
     CGroup: /system.slice/crond.service
             └─1089 /usr/sbin/crond -n

Mar 14 05:38:10 workstation systemd[1]: Started Command Scheduler.
Warning: some journal files were not opened due to insufficient permissions.

Examinons les champs clés de la sortie :

Loaded : Cette ligne vous indique si le fichier de configuration de l'unité de service a été traité. Elle affiche également le chemin vers le fichier d'unité (/usr/lib/systemd/system/crond.service) et son état d'activation (enabled signifie qu'il est configuré pour démarrer au boot).
Active : C'est crucial. Cela indique l'état actuel du service. active (running) signifie que le service est actuellement actif et que ses processus sont en cours d'exécution. Elle indique également depuis combien de temps il est actif. D'autres états peuvent être inactive (non en cours d'exécution), active (exited) (a terminé une tâche ponctuelle) ou failed (a rencontré une erreur).
Main PID : L'ID de processus (PID) du processus principal associé au service, ainsi que le nom de la commande.
Tasks : Le nombre de tâches (threads) que le service utilise actuellement.
Memory : La quantité de mémoire consommée par le service.
CPU : Le temps CPU consommé par le service.
CGroup : Informations sur le groupe de contrôle (cgroup) auquel appartient le service, utilisé pour la gestion des ressources.
Les lignes sous CGroup affichent les entrées de journal récentes liées au service, fournissant des informations sur son démarrage et ses activités en cours.

En plus de systemctl status, il existe des commandes plus simples pour vérifier rapidement des aspects spécifiques de l'état d'un service :

Pour vérifier si un service est actif :
```
systemctl is-active crond.service
```
Sortie attendue :
```
active
```
Pour vérifier si un service est activé (configuré pour démarrer au boot) :
```
systemctl is-enabled crond.service
```
Sortie attendue :
```
enabled
```
Pour vérifier si un service a échoué :
```
systemctl is-failed crond.service
```
Sortie attendue (si le service fonctionne correctement) :
```
active
```
Si un service a rencontré des problèmes lors du démarrage ou de l'exécution, cette commande renverrait failed.

Ces commandes sont utiles pour les scripts ou les vérifications rapides lorsque vous n'avez pas besoin de la sortie détaillée complète de systemctl status.

Démarrer, arrêter et redémarrer un service avec systemctl

Dans cette étape, vous apprendrez à gérer le cycle de vie des services système à l'aide des commandes systemctl. Vous vous entraînerez à démarrer, arrêter et redémarrer un service. Pour cet exercice, nous utiliserons un service fictif que nous allons créer. Cette approche garantit que nous pouvons manipuler un service en toute sécurité sans affecter les fonctions critiques du système.

Tout d'abord, créons un fichier d'unité de service simple. Ce fichier définira un service qui écrit simplement un horodatage dans un fichier journal toutes les quelques secondes.

Créez un nouveau fichier d'unité de service nommé mytest.service directement dans le répertoire système de systemd en utilisant nano :

sudo nano /etc/systemd/system/mytest.service

Collez le contenu suivant dans l'éditeur nano :

[Unit]
Description=My Test Service
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service is running." >> /tmp/mytest.log; sleep 5; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure

[Install]
WantedBy=multi-user.target

[Unit] : Contient des informations génériques sur l'unité. Description fournit un nom lisible par l'homme, et After=network.target spécifie que ce service doit démarrer après que le réseau soit opérationnel.
[Service] : Définit le comportement du service.
- Type=simple : Indique un type de service simple où la commande ExecStart est le processus principal.
- ExecStart : La commande à exécuter lorsque le service démarre. Ici, il s'agit d'une boucle bash qui écrit un message horodaté dans /tmp/mytest.log toutes les 5 secondes.
- ExecStop : La commande à exécuter lorsque le service s'arrête. Elle écrit un message d'arrêt dans le journal.
- Restart=on-failure : Configure le service pour qu'il redémarre s'il se termine avec un état différent de zéro.
[Install] : Contient des informations sur la façon dont le service doit être installé. WantedBy=multi-user.target signifie que ce service doit être démarré lorsque le système atteint le niveau d'exécution multi-utilisateur.

Enregistrez le fichier en appuyant sur Ctrl+X, puis Y pour confirmer, et Enter pour enregistrer.

Maintenant, rechargez le démon systemd pour qu'il reconnaisse le nouveau fichier de service :

sudo systemctl daemon-reload

Démarrer un service

Pour démarrer un service, utilisez la commande systemctl start.

Exécutez la commande suivante pour démarrer mytest.service. Notez que nous devons utiliser sudo car les opérations systemctl nécessitent généralement des privilèges root.

sudo systemctl start mytest.service

Il n'y aura pas de sortie immédiate si la commande réussit.

Maintenant, vérifiez que le service est en cours d'exécution en vérifiant son état :

systemctl status mytest.service

Vous devriez voir une sortie indiquant que le service est active (running) :

● mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: active (running) since ...
   Main PID: ... (bash)
      Tasks: 2 (limit: ...)
     Memory: ...
        CPU: ...
     CGroup: /system.slice/mytest.service
             ├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
             └─... sleep 5

...output omitted...

Vous pouvez également vérifier le fichier journal pour voir si le service écrit des messages :

tail -f /tmp/mytest.log

Vous devriez voir de nouvelles lignes apparaître toutes les 5 secondes, similaires à ceci :

Tue Jul 22 09:15:09 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:14 AM CST 2025: My Test Service is running.

Appuyez sur Ctrl+C pour quitter tail.

Arrêter un service

Pour arrêter un service en cours d'exécution, utilisez la commande systemctl stop.

Exécutez la commande suivante pour arrêter mytest.service :

sudo systemctl stop mytest.service

Encore une fois, il n'y aura pas de sortie immédiate.

Vérifiez que le service s'est arrêté :

systemctl status mytest.service

La sortie devrait maintenant afficher Active: inactive (dead) :

○ mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: inactive (dead) since ...
...output omitted...

Vérifiez à nouveau le fichier journal /tmp/mytest.log. Vous devriez voir le message "My Test Service stopped." et aucun nouveau message "running".

tail /tmp/mytest.log

La sortie ressemblera à ceci :

Tue Jul 22 09:15:24 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.

Redémarrer un service

Pour redémarrer un service, utilisez la commande systemctl restart. Cette commande arrête d'abord le service, puis le redémarre. C'est utile lorsque vous avez apporté des modifications à la configuration d'un service et que vous souhaitez qu'elles prennent effet.

Exécutez la commande suivante pour redémarrer mytest.service :

sudo systemctl restart mytest.service

Vérifiez que le service est à nouveau en cours d'exécution :

systemctl status mytest.service

Vous devriez voir Active: active (running) à nouveau, et le Main PID sera probablement un nouveau numéro, indiquant qu'un nouveau processus a démarré.

● mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: active (running) since ...
   Main PID: ... (bash)
      Tasks: 2 (limit: ...)
     Memory: ...
        CPU: ...
     CGroup: /system.slice/mytest.service
             ├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
             └─... sleep 5
...output omitted...

Vérifiez le fichier journal /tmp/mytest.log pour confirmer que le service a repris l'écriture des messages "running".

tail -f /tmp/mytest.log

Vous devriez voir un message "stopped" suivi de nouveaux messages "running" :

Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Tue Jul 22 09:15:40 AM CST 2025: My Test Service is running.

Appuyez sur Ctrl+C pour quitter tail.

Appliquer des modifications de configuration à un service

Dans cette étape, vous apprendrez à recharger les configurations des services. Certains services peuvent appliquer des modifications à leurs fichiers de configuration sans nécessiter un redémarrage complet. C'est ce qu'on appelle "recharger" le service. Le rechargement est généralement préférable au redémarrage car il évite les temps d'arrêt du service et préserve les connexions ou les états existants. Lorsqu'un service est rechargé, son ID de processus (PID) reste généralement le même, contrairement à un redémarrage complet où le PID change.

Nous continuerons à utiliser notre mytest.service de l'étape précédente. Nous modifierons son comportement, puis tenterons de le recharger pour voir ce qui se passe.

Tout d'abord, assurez-vous que mytest.service est en cours d'exécution. S'il ne l'est pas, démarrez-le :

sudo systemctl start mytest.service

Vérifiez son état et notez son Main PID :

systemctl status mytest.service

Maintenant, modifions le fichier mytest.service pour changer le message qu'il enregistre et l'intervalle. Nous modifierons le message du journal et la durée du sleep.

Ouvrez /etc/systemd/system/mytest.service avec nano :

sudo nano /etc/systemd/system/mytest.service

Modifiez la ligne ExecStart comme suit, en changeant le message et le temps de sleep de 5 à 2 secondes :

[Unit]
Description=My Test Service
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service (reloaded) is running." >> /tmp/mytest.log; sleep 2; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure

[Install]
WantedBy=multi-user.target

Enregistrez le fichier en appuyant sur Ctrl+X, puis Y, et Enter.

Après avoir enregistré les modifications, vous devez informer systemd que la configuration du service a changé.

sudo systemctl daemon-reload

Maintenant, essayons de recharger le service pour appliquer les modifications :

sudo systemctl reload mytest.service

Vous rencontrerez probablement une erreur :

Failed to reload mytest.service: Job type reload is not applicable for unit mytest.service.

Cette erreur se produit parce que notre service simple n'est pas configuré pour gérer une demande de rechargement. Pour qu'un service soit rechargeable, son fichier d'unité doit inclure une directive ExecReload, qui spécifie la commande à exécuter pour recharger la configuration. Comme notre mytest.service en est dépourvu, systemd ne sait pas comment le recharger.

Dans des situations comme celle-ci, systemd fournit une commande pratique : reload-or-restart. Cette commande tentera de recharger le service, mais si le rechargement n'est pas pris en charge, elle reviendra à un redémarrage du service. C'est souvent un moyen plus sûr et plus efficace d'appliquer des modifications de configuration.

Utilisons reload-or-restart maintenant :

sudo systemctl reload-or-restart mytest.service

Cette commande devrait réussir. Maintenant, vérifiez à nouveau l'état du service :

systemctl status mytest.service

Observez le Main PID. Comme notre service a été redémarré (car il n'a pas pu être rechargé), vous remarquerez que le Main PID est un nouveau numéro. Cela confirme que l'ancien processus a été arrêté et qu'un nouveau a été démarré avec la configuration mise à jour.

Enfin, vérifions le fichier /tmp/mytest.log pour voir si les modifications ont pris effet.

tail -f /tmp/mytest.log

Vous devriez voir le nouveau message de journal "My Test Service (reloaded) is running." apparaître toutes les 2 secondes. Appuyez sur Ctrl+C pour quitter tail.

Activer et désactiver des services au boot avec systemctl

Dans cette étape, vous apprendrez à configurer les services pour qu'ils démarrent automatiquement au boot (activer) ou pour les empêcher de démarrer au boot (désactiver). C'est crucial pour gérer les ressources système et garantir que les services nécessaires sont disponibles au démarrage du système.

Dans un environnement systemd typique, l'activation d'un service crée des liens symboliques dans les répertoires de configuration systemd appropriés (par exemple, /etc/systemd/system/multi-user.target.wants/) qui pointent vers le fichier d'unité du service. La désactivation d'un service supprime ces liens.

Comme nous sommes dans un environnement conteneurisé où systemd pourrait ne pas être pleinement opérationnel au sens traditionnel, les commandes enable et disable pourraient ne pas créer de liens symboliques réels dans le répertoire /etc/systemd/system qui persistent après les redémarrages du conteneur. Cependant, systemctl traite toujours ces commandes et met à jour son état interne, ce que nous allons observer.

Nous continuerons à utiliser notre mytest.service pour cette démonstration.

Tout d'abord, assurez-vous que mytest.service est arrêté depuis l'étape précédente :

sudo systemctl stop mytest.service

Activer un service

Pour activer un service, utilisez la commande systemctl enable. Cette commande configure le service pour qu'il démarre automatiquement au démarrage du système.

Exécutez la commande suivante pour activer mytest.service :

sudo systemctl enable mytest.service

Vous pourriez voir une sortie similaire à celle-ci, indiquant qu'un lien symbolique serait créé dans un environnement systemd complet :

Created symlink /etc/systemd/system/multi-user.target.wants/mytest.service → /etc/systemd/system/mytest.service.

Maintenant, vérifiez que le service est activé en utilisant systemctl is-enabled :

systemctl is-enabled mytest.service

Sortie attendue :

enabled

Cela confirme que systemctl considère désormais mytest.service comme activé pour le boot.

Vous pouvez également combiner l'activation et le démarrage d'un service en une seule commande en utilisant l'option --now. C'est un moyen pratique de s'assurer qu'un service est à la fois en cours d'exécution immédiatement et configuré pour démarrer lors des futurs boots.

Tout d'abord, désactivons-le pour préparer la démonstration de --now :

sudo systemctl disable mytest.service

Maintenant, activez-le et démarrez-le simultanément :

sudo systemctl enable --now mytest.service

Vérifiez son état et son activation :

systemctl status mytest.service
systemctl is-enabled mytest.service

Vous devriez voir Active: active (running) avec la commande status et enabled avec la commande is-enabled.

Désactiver un service

Pour désactiver un service, utilisez la commande systemctl disable. Cette commande supprime la configuration qui provoque le démarrage du service au boot.

Exécutez la commande suivante pour désactiver mytest.service :

sudo systemctl disable mytest.service

Vous pourriez voir une sortie indiquant la suppression du lien symbolique :

Removed /etc/systemd/system/multi-user.target.wants/mytest.service.

Maintenant, vérifiez que le service est désactivé :

systemctl is-enabled mytest.service

Sortie attendue :

disabled

Comme pour l'activation, vous pouvez combiner la désactivation et l'arrêt d'un service en utilisant l'option --now. Cela arrêtera le service immédiatement et l'empêchera de démarrer lors des futurs boots.

sudo systemctl disable --now mytest.service

Vérifiez son état et son activation :

systemctl status mytest.service
systemctl is-enabled mytest.service

Vous devriez voir Active: inactive (dead) avec la commande status et disabled avec la commande is-enabled.

Ceci conclut la démonstration de l'activation et de la désactivation des services. N'oubliez pas que dans un environnement systemd réel, ces commandes manipulent directement la configuration de démarrage.

Masquer et démasquer des services avec systemctl

Dans cette dernière étape, vous apprendrez à masquer et démasquer des services. Masquer un service est un moyen puissant d'empêcher son démarrage, que ce soit manuellement ou automatiquement au boot.

Lorsque vous masquez un service, systemd crée un lien symbolique de /etc/systemd/system/<service-name>.service vers /dev/null, rendant effectivement le fichier d'unité de service indisponible pour systemd. C'est une alternative plus forte à disable.

Ce mécanisme fonctionne mieux pour les services définis dans /usr/lib/systemd/system, là où les paquets installent leurs fichiers de service. La commande mask crée un fichier "vide" de remplacement dans /etc/systemd/system. Cependant, comme vous l'avez découvert, si vous essayez de masquer un service que vous avez créé directement dans /etc/systemd/system (comme notre mytest.service), la commande peut échouer car elle est conçue pour ne pas écraser un fichier de configuration existant, ce qui entraînerait une perte de données.

Pour démontrer correctement le masquage, nous utiliserons un service préexistant, atd.service.

Tout d'abord, vérifions l'état actuel de atd.service. Il devrait être actif et activé.

systemctl status atd.service

La sortie sera similaire à celle-ci, montrant que le service est actif et en cours d'exécution :

● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-07-22 09:13:06 CST; 22min ago
       Docs: man:atd(8)
   Main PID: 1222 (atd)
      Tasks: 1 (limit: 22509)
     Memory: 900.0K
        CPU: 5ms
     CGroup: /system.slice/atd.service
             └─1222 /usr/sbin/atd -f

Masquer un service

Il est recommandé d'arrêter un service avant de le masquer.

sudo systemctl stop atd.service

Maintenant, exécutez la commande suivante pour masquer atd.service :

sudo systemctl mask atd.service

Vous verrez une sortie indiquant la création d'un lien symbolique vers /dev/null :

Created symlink /etc/systemd/system/atd.service → /dev/null.

Maintenant, essayez de démarrer le service masqué :

sudo systemctl start atd.service

Vous recevrez un message d'erreur indiquant que le service est masqué :

Failed to start atd.service: Unit atd.service is masked.

Vous pouvez également vérifier l'état du service en utilisant systemctl list-unit-files :

systemctl list-unit-files --type=service | grep atd.service | tee ~/project/atd-mask-state.txt

La sortie devrait afficher masked pour atd.service :

atd.service                            masked      enabled

Cela confirme que le service est maintenant masqué et ne peut pas être démarré.

Démasquer un service

Pour démasquer un service, utilisez la commande systemctl unmask. Cette commande supprime le lien symbolique vers /dev/null, restaurant le fichier de service original depuis /usr/lib/systemd/system.

Exécutez la commande suivante pour démasquer atd.service :

sudo systemctl unmask atd.service

Vous verrez une sortie indiquant la suppression du lien symbolique :

Removed "/etc/systemd/system/atd.service".

Après le démasquage, démarrez à nouveau le service car unmask supprime uniquement le lien /dev/null et ne redémarre pas le service pour vous.

sudo systemctl start atd.service

Maintenant, vérifiez l'état du service :

systemctl status atd.service

Vous devriez voir Active: active (running), similaire à ceci :

● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-07-22 09:36:10 CST; 2s ago
       Docs: man:atd(8)
   Main PID: 7372 (atd)
      Tasks: 1 (limit: 22509)
     Memory: 868.0K
        CPU: 6ms
     CGroup: /system.slice/atd.service
             └─7372 /usr/sbin/atd -f

Ceci conclut le laboratoire sur le contrôle des services et des démons. Vous avez appris à afficher, démarrer, arrêter, redémarrer, recharger, activer, désactiver, masquer et démasquer des services à l'aide de systemctl.

Résumé

Dans ce laboratoire, nous avons acquis une expérience pratique de la gestion des services système à l'aide de la commande systemctl, même dans un environnement conteneurisé où systemd pourrait ne pas être le système d'initialisation principal. Nous avons appris à lister toutes les unités de service chargées et actives à l'aide de systemctl list-units --type=service, en comprenant les colonnes UNIT, LOAD, ACTIVE et SUB pour interpréter les états des services.

De plus, nous avons exploré les opérations essentielles de gestion des services : vérifier l'état d'un service spécifique avec systemctl status, et contrôler le cycle de vie des services en les démarrant, les arrêtant et les redémarrant. Nous avons également couvert la manière de recharger les configurations des services, d'activer et de désactiver des services pour contrôler leur comportement au boot, ainsi que les concepts avancés de masquage et de démasquage des services pour les empêcher de démarrer. Cet ensemble complet de compétences constitue une base solide pour la gestion des services sur les systèmes RHEL.