JOUR 06 : Le surveillant des processus

Introduction

Bienvenue, administrateur système junior ! C'est un lundi matin chargé chez « LabEx », et une alerte critique vient de tomber : le serveur d'application principal subit un ralentissement important, impactant tous les utilisateurs. Les administrateurs seniors sont retenus dans une réunion d'urgence, et c'est à vous d'enquêter et de stabiliser le système.

C'est votre moment de briller. Votre mission est de plonger dans la ligne de commande du serveur, de diagnostiquer le problème en inspectant les processus en cours d'exécution, de neutraliser les coupables qui accaparent les ressources et de vous assurer que les services essentiels restent opérationnels. À la fin de ce défi, vous aurez prouvé votre capacité à gérer un environnement Linux réel sous pression, une compétence fondamentale pour tout administrateur système.

Lister les processus système actifs

Votre première étape en tant que surveillant des processus est d'obtenir une image complète de ce qui s'exécute actuellement sur le serveur. Un instantané statique de tous les processus actifs vous aidera à commencer votre enquête et à identifier toute anomalie.

Tâches

• Utilisez une commande unique pour générer une liste détaillée de tous les processus en cours d'exécution sur le système.

Exigences

• La commande doit afficher les processus de tous les utilisateurs, pas seulement les vôtres.
• Le format de sortie doit être orienté utilisateur, affichant des détails tels que l'utilisateur propriétaire du processus, l'utilisation du processeur (CPU) et de la mémoire, ainsi que la commande complète qui l'a lancé.

Exemples

Après avoir exécuté la commande, vous devriez voir une sortie similaire à celle-ci :

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1 169848  9064 ?        Ss   08:30   0:02 /sbin/init
labex     1234  0.0  0.0   2324   564 pts/0    S+   08:35   0:00 bash /home/labex/project/resource_hog.sh
labex     1235  0.0  0.0   2324   564 ?        S    08:35   0:00 bash /home/labex/project/critical_service.sh
...

La sortie affichera plusieurs processus avec des colonnes pour l'utilisateur, l'identifiant du processus (PID), l'utilisation du CPU, l'utilisation de la mémoire et la commande qui a démarré chaque processus.

Indices

• La commande la plus courante pour cette tâche est ps.
• Réfléchissez aux options de la commande ps qui permettraient d'afficher les processus de tous les utilisateurs (all), dans un format convivial pour l'utilisateur (user-friendly), et d'inclure les processus non rattachés à un terminal (x).

Surveiller l'utilisation des ressources en temps réel

La liste statique de ps était un bon début, mais la charge du serveur change à chaque seconde. Vous avez besoin d'une vue dynamique et en direct pour voir quel processus cause activement le ralentissement. Il est temps de sortir un outil de surveillance plus puissant.

Tâches

• Lancez un utilitaire interactif en ligne de commande pour surveiller les processus système et leur utilisation des ressources en temps réel.
• Identifiez le nom du script qui consomme le plus de CPU.

Exigences

• Vous devez utiliser un outil qui fournit une vue en temps réel et continuellement mise à jour des processus système.
• L'outil doit permettre de trier les processus par utilisation du CPU par défaut.
• Une fois que vous avez identifié le principal consommateur, quittez l'outil pour passer à l'étape suivante.

Exemples

Lorsque vous lancez l'outil de surveillance, vous devriez voir un affichage interactif qui se met à jour automatiquement, ressemblant à ceci :

top - 09:15:30 up  1:45,  1 user,  load average: 1.50, 1.20, 0.85
Tasks: 105 total,   2 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.0 us,  5.0 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   2048.0 total,    850.4 free,    950.2 used,    247.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used,      0.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 labex     20   0   12884   1564   1320 R  95.0   0.1   2:15.30 bash /home/labex/project/resource_hog.sh
 1235 labex     20   0   12884   1564   1320 S   0.0   0.1   0:00.00 bash /home/labex/project/critical_service.sh
    1 root      20   0  169848   9064   6868 S   0.0   0.4   0:02.15 systemd
...

L'affichage montrera les statistiques du système en haut et une liste de processus triés par utilisation du CPU, avec le processus le plus gourmand en haut.

Indices

• Cette commande populaire est souvent appelée le « Gestionnaire des tâches » du monde Linux.
• Vous pouvez quitter cet outil interactif en appuyant sur la touche q.

Identifier les processus clés

Vous avez trouvé le fauteur de troubles : resource_hog.sh. Cependant, un bon administrateur système ne termine pas les processus au hasard. Vous avez également remarqué que critical_service.sh est en cours d'exécution. Avant d'agir contre le processus gourmand, vous devez identifier et comprendre tous les processus clés du système.

Tâches

• Trouvez l'identifiant de processus (PID) du script critical_service.sh.
• Vérifiez que le service critique fonctionne correctement.

Exigences

• Vous devez utiliser la commande pgrep pour trouver le PID du processus exécutant critical_service.sh.
• La commande doit localiser avec succès le processus en cours et afficher son PID.

Exemples

Après avoir trouvé le PID avec pgrep, vous devriez voir une sortie comme :

1235

Ce nombre (1235 dans cet exemple) est le PID du processus du service critique.

Vous pouvez vérifier les détails du processus en utilisant :

ps -p 1235 -o pid,ppid,cmd

Ce qui devrait afficher une sortie similaire à :

PID PPID CMD
1235 1 /bin/bash /home/labex/project/critical_service.sh

Indices

• pgrep peut trouver un PID basé sur le nom d'un processus.
• Utilisez pgrep -f pour effectuer une recherche sur la ligne de commande complète.

Terminer un processus récalcitrant

Maintenant que vous avez identifié les processus clés, il est temps de s'occuper de resource_hog.sh qui ralentit le serveur. Vous devez terminer ce processus pour restaurer un fonctionnement normal.

Tâches

• Terminez le processus resource_hog.sh.

Exigences

• Vous devez utiliser une commande capable de terminer un processus en fonction de son nom, sans avoir besoin de chercher son PID au préalable.
• Utilisez la commande pkill pour arrêter le script resource_hog.sh.

Exemples

Pour vérifier que le processus a été terminé, vous pouvez consulter la liste des processus après coup. Avant la terminaison, vous pourriez voir :

labex 1234 95.0 0.0 2324 564 pts/0 R+ 09:15 5:00 bash /home/labex/project/resource_hog.sh

Après une terminaison réussie, l'exécution de la même commande de vérification ne devrait montrer aucun processus correspondant (seulement la commande grep elle-même) :

labex 2345 0.0 0.0 2324 564 pts/0 S+ 09:20 0:00 grep resource_hog

Indices

• La commande pkill envoie un signal de terminaison aux processus en fonction de leur nom.
• Après avoir exécuté la commande, vous pouvez utiliser ps aux | grep resource_hog pour vérifier que le processus n'est plus en cours d'exécution.

Démarrer et gérer des processus en arrière-plan

Le serveur est à nouveau stable ! Excellent travail. Juste au moment où vous vous apprêtez à faire une pause, un développeur vous envoie un message. Il a besoin que vous exécutiez un script de longue durée, data_processor.sh, sur le serveur. Vous ne pouvez pas garder votre session de terminal ouverte pendant des heures juste pour ce script. Vous devez l'exécuter en arrière-plan afin qu'il continue même après votre déconnexion.

Tâches

• Démarrez le script data_processor.sh de manière à ce qu'il s'exécute en arrière-plan et soit immunisé contre les déconnexions (c'est-à-dire qu'il ne s'arrêtera pas si vous fermez votre terminal).

Exigences

• Vous devez vous trouver dans le répertoire ~/project.
• Utilisez la commande nohup pour exécuter le script.
• Utilisez l'opérateur & pour envoyer le processus en arrière-plan.
• Redirigez toute la sortie (sortie standard et erreur standard) du script vers un fichier nommé processor.log.

Exemples

Après avoir démarré avec succès le script en arrière-plan, vous devriez voir une sortie similaire à :

[1] 3456
nohup: ignoring input and appending output to 'processor.log'

Le [1] 3456 indique le numéro de tâche (job) et l'identifiant du processus (PID). Vous pouvez vérifier que le script s'exécute en consultant le fichier journal :

cat processor.log

Cela pourrait afficher une sortie comme :

Starting data processing at Mon Sep 11 10:30:00 UTC 2025

Et vous pouvez confirmer que le processus est toujours actif :

ps aux | grep data_processor

Ce qui devrait montrer que le processus en arrière-plan est en cours d'exécution.

Indices

• La commande nohup signifie « no hang up » (pas de raccrochage).
• Le symbole & à la fin d'une commande indique au shell de l'exécuter en tant que tâche de fond.
• Vous pouvez rediriger la sortie standard avec > et l'erreur standard avec 2>&1.

Résumé

Félicitations, administrateur ! Vous avez résolu avec succès un problème critique de performance du serveur et démontré votre maîtrise de la gestion des processus Linux. Le serveur est stable, les services critiques sont priorisés et les tâches de longue durée tournent tranquillement en arrière-plan.

Dans ce défi, vous avez prouvé votre capacité à :

• Lister et inspecter tous les processus en cours d'exécution avec ps.
• Surveiller les ressources système en temps réel avec top.
• Identifier les processus importants à l'aide de pgrep.
• Terminer proprement les processus récalcitrants avec pkill.
• Exécuter et gérer des tâches en arrière-plan qui persistent après la déconnexion avec nohup et &.

Ce sont des compétences fondamentales et de haute valeur, essentielles pour tout rôle en administration système, DevOps ou développement backend. Vous avez transformé une crise potentielle en une opportunité de démontrer votre expertise. Beau travail !