Introduction
Un système Linux en fonctionnement ne se limite pas à ses fichiers. Le noyau gère le matériel et les processus. Chaque commande s’exécute comme un processus doté d’un identifiant, et le shell suit les tâches exécutées au premier plan ou en arrière-plan. Les administrateurs commencent par observer cet état, puis agissent sur le processus pertinent le plus ciblé.
Dans ce laboratoire, vous allez identifier le système d’exploitation et le noyau, interpréter la durée de fonctionnement et les charges moyennes, examiner les relations entre les processus, rechercher des processus par leur nom, envoyer des signaux d’arrêt, vous exercer au contrôle interactif des tâches, interpréter le statut de sortie, exécuter une commande détachée avec nohup et lire les messages récents du noyau.
Identifier le système et interpréter la charge
Dans cette étape, vous allez identifier le noyau et la distribution, vérifier depuis combien de temps le système fonctionne et comprendre ce que représentent les charges moyennes.
Créez un espace de travail et placez-vous dedans :
mkdir -p /home/labex/project/process-lab
cd /home/labex/project/process-lab
La commande uname affiche des informations sur le noyau. Les options -s, -r et -m sélectionnent respectivement le nom du noyau, sa version et l’architecture de la machine :
uname -srm
uname -a affiche tous les champs disponibles sur une seule ligne :
uname -a
Le noyau n’est pas la même chose que la distribution Linux. Lisez les métadonnées de la distribution :
cat /etc/os-release
Repérez notamment les champs NAME, VERSION et ID. Vérifiez ensuite la durée de fonctionnement et la charge :
uptime
La sortie indique l’heure actuelle, depuis combien de temps le système fonctionne, le nombre d’utilisateurs connectés et trois charges moyennes. Ces moyennes décrivent la quantité de travail exécutable ou non interruptible sur environ 1, 5 et 15 minutes. Il ne s’agit pas de pourcentages ; leur signification dépend notamment du nombre de cœurs processeur.
Affichez l’enregistrement compact de la charge fourni par le noyau :
cat /proc/loadavg
Les trois premières valeurs correspondent aux charges moyennes. Les champs suivants indiquent les tâches exécutables et l’identifiant du processus attribué le plus récemment.
Enregistrez un petit résumé du système pour pouvoir le consulter plus tard :
uname -srm > system-summary.txt
uptime >> system-summary.txt
cat system-summary.txt
Le fichier doit contenir une ligne sur le noyau et une ligne sur la durée de fonctionnement.
Inspecter les processus et l’activité des ressources
Dans cette étape, vous allez examiner les identifiants des processus, leurs relations avec les processus parents, leurs états et un instantané de l’activité des ressources du système.
Un processus est un programme en cours d’exécution. Chaque processus possède un identifiant de processus, ou PID. La plupart des processus possèdent également un identifiant de processus parent, ou PPID, qui désigne le processus à l’origine de leur démarrage.
La commande ps affiche un instantané des processus. Sélectionnez des champs utiles et triez-les par PID :
cd /home/labex/project/process-lab
ps -eo pid,ppid,user,stat,comm --sort=pid | head -n 15
L’option -e sélectionne tous les processus et -o définit les colonnes :
PIDest l’identifiant du processus.PPIDest l’identifiant du processus parent.USERest le propriétaire du processus.STATest l’état du processus, accompagné éventuellement de drapeaux.COMMANDest le nom de l’exécutable.
Les principales lettres d’état sont notamment R pour un processus en cours d’exécution, S pour une veille interruptible, D pour une veille non interruptible, T pour un processus arrêté et Z pour un processus zombie. Un processus en veille attend souvent simplement du travail.
La forme ps aux, de style BSD, fournit les colonnes d’utilisation du processeur et de la mémoire ainsi que les lignes de commande complètes :
ps aux | head -n 10
Utilisée de manière interactive, la commande top actualise continuellement l’affichage. Le mode batch produit un instantané stable : -b sélectionne la sortie batch et -n 1 demande une seule actualisation.
top -b -n 1 | head -n 12
L’en-tête résume la durée de fonctionnement, la charge, l’état des tâches, l’utilisation du processeur et la mémoire. Le tableau des processus situé en dessous vous aide à repérer ceux qui consomment activement des ressources.
Ouvrez maintenant l’affichage interactif :
top
Observez la mise à jour des valeurs, repérez les colonnes %CPU et %MEM, puis appuyez sur q pour revenir au shell. Le mode interactif de top est utile pour observer les changements au fil du temps ; le mode batch est préférable lorsque la sortie doit être enregistrée ou traitée par une autre commande.
Enregistrez un instantané ciblé des processus afin de disposer d’un résultat consultable :
ps -eo pid,ppid,user,stat,comm --sort=pid > process-snapshot.txt
head -n 5 process-snapshot.txt
Démarrer et localiser un processus d’exercice
Dans cette étape, vous allez démarrer un processus d’arrière-plan inoffensif, récupérer son PID et le localiser avec ps et pgrep.
Le & final demande au shell d’exécuter une commande en arrière-plan et de rendre immédiatement l’invite de commande. Démarrez un processus sleep de cinq minutes avec le nom visible labex-worker :
cd /home/labex/project/process-lab
bash -c 'exec -a labex-worker sleep 300' &
La valeur spéciale du shell $! contient le PID du dernier processus d’arrière-plan démarré. Enregistrez-le avant de démarrer une autre commande en arrière-plan :
worker_pid=$!
echo "$worker_pid" > worker.pid
Inspectez précisément ce processus. L’option -p sélectionne un PID et -o choisit les champs à afficher :
ps -o pid,ppid,user,stat,etime,args -p "$worker_pid"
ETIME indique la durée d’exécution écoulée, tandis que ARGS inclut le nom visible du processus. Utilisez pgrep -f pour rechercher dans la ligne de commande complète ; -a l’affiche également :
pgrep -af labex-worker
Le PID affiché par pgrep doit correspondre à celui enregistré dans worker.pid. Une recherche fondée sur un motif précis est plus sûre qu’une action sur tous les processus correspondant à un nom trop général.
Arrêter des processus avec des signaux
Dans cette étape, vous allez demander un arrêt normal avec SIGTERM et utiliser SIGKILL uniquement pour un processus conçu pour ignorer cette demande.
La commande kill envoie un signal à un PID. Sans signal explicite, elle envoie SIGTERM, le signal 15. SIGTERM demande un arrêt ordonné et laisse au processus la possibilité d’effectuer son nettoyage.
Lisez le PID du processus de travail et envoyez SIGTERM :
cd /home/labex/project/process-lab
worker_pid=$(cat worker.pid)
kill "$worker_pid"
sleep 1
L’échec attendu de la commande ps suivante confirme que le processus s’est terminé :
ps -p "$worker_pid" || echo "labex-worker stopped after SIGTERM"
Démarrez maintenant un processus contrôlé qui ignore volontairement SIGTERM :
bash -c 'trap "" TERM; exec -a labex-stubborn sleep 300' &
stubborn_pid=$!
echo "$stubborn_pid" > stubborn.pid
Laissez un instant au nouveau shell pour installer son gestionnaire de signaux :
sleep 1
Envoyez SIGTERM, attendez brièvement, puis inspectez le processus :
kill -TERM "$stubborn_pid"
sleep 1
ps -o pid,stat,args -p "$stubborn_pid"
Le processus doit toujours être présent, car ce processus d’exercice ignore SIGTERM. SIGKILL, le signal 9, ne peut être ni intercepté ni ignoré. Utilisez-le uniquement lorsqu’un signal d’arrêt normal reste sans effet :
kill -KILL "$stubborn_pid"
Récupérez la tâche d’arrière-plan terminée. Le statut différent de zéro est attendu ; || true permet donc à la séquence d’exercice de continuer :
wait "$stubborn_pid" 2>/dev/null || true
ps -p "$stubborn_pid" || echo "labex-stubborn required SIGKILL"
SIGKILL ne laisse au processus aucune possibilité d’enregistrer son état ou de libérer proprement les ressources de l’application. Il s’agit donc d’une solution de dernier recours.
kill cible un PID connu. Lorsque vous devez sélectionner un processus par son nom ou par sa ligne de commande complète, pkill combine la recherche et l’envoi du signal. Démarrez un autre processus contrôlé avec une ligne de commande distinctive :
bash -c 'exec -a labex-helper sleep 300' &
helper_pid=$!
echo "$helper_pid" > helper.pid
Vérifiez la correspondance exacte de la ligne de commande complète avant d’agir :
pgrep -af '^labex-helper 300$'
Envoyez SIGTERM à cette correspondance exacte avec pkill -f. Les ancres ^ et $ empêchent ce motif d’exercice de correspondre à des lignes de commande sans rapport :
pkill -TERM -f '^labex-helper 300$'
wait "$helper_pid" 2>/dev/null || true
ps -p "$helper_pid" || echo "labex-helper stopped by pkill"
Utilisez des motifs pkill précis et vérifiez d’abord les correspondances avec pgrep ; des motifs trop généraux peuvent arrêter davantage de processus que prévu.
Contrôler les tâches au premier plan et en arrière-plan
Dans cette étape, vous allez suspendre une commande au premier plan, la reprendre en arrière-plan, la ramener au premier plan, puis l’interrompre.
Le contrôle des tâches concerne le shell interactif actuel. Démarrez un processus sleep au premier plan avec un nom reconnaissable :
cd /home/labex/project/process-lab
bash -c 'exec -a labex-job sleep 300'
Le terminal est maintenant occupé par le processus au premier plan. Appuyez sur Ctrl+Z. Le shell envoie un signal d’arrêt et rend l’invite de commande.
Affichez les tâches connues de ce shell. L’option -l inclut l’identifiant du processus :
jobs -l
Vous devez voir une tâche Stopped. Reprenez la tâche numéro 1 en arrière-plan :
bg %1
jobs -l
L’état doit maintenant être Running et l’invite reste disponible. Ramenez la tâche au premier plan :
fg %1
Appuyez sur Ctrl+C pour envoyer un signal d’interruption à la tâche au premier plan. L’invite doit réapparaître. Vérifiez qu’il ne reste aucune tâche d’exercice :
pgrep -af labex-job || echo "No labex-job process remains"
Créez un marqueur une fois la séquence interactive terminée :
touch job-control.done
Utilisez le contrôle des tâches pour les commandes attachées au terminal actuel. Plus tard, vous utiliserez nohup pour les tâches qui ne doivent pas dépendre de la session du terminal.
Lire le statut de sortie et exécuter une tâche détachée
Dans cette étape, vous allez interpréter le statut de sortie d’une commande et exécuter une courte tâche en arrière-plan dont la sortie reste disponible indépendamment de l’affichage du terminal.
Chaque commande renvoie un statut entier. La valeur zéro indique une réussite ; une valeur différente de zéro indique un échec d’un certain type. La variable du shell $? contient le statut de la commande qui vient de se terminer.
Exécutez une commande réussie, puis affichez immédiatement son statut :
cd /home/labex/project/process-lab
true
echo "true status: $?"
Le résultat est 0. Exécutez maintenant une commande qui ne peut pas trouver son chemin :
ls missing-path
Enregistrez son statut avant qu’une autre commande ne remplace la valeur de $? :
missing_status=$?
echo "missing-path status: $missing_status"
La valeur est différente de zéro. Enregistrez les deux interprétations attendues :
printf 'success=0\nfailure=%s\n' "$missing_status" > exit-status.txt
La commande nohup fait ignorer au programme le signal de déconnexion du terminal. Le & final le démarre en arrière-plan. La redirection < /dev/null déconnecte l’entrée du terminal, tandis que > nohup.log 2>&1 envoie les deux flux de sortie vers un journal :
nohup bash -c 'for item in one two three; do echo "background: $item"; sleep 1; done' < /dev/null > nohup.log 2>&1 &
Enregistrez le PID d’arrière-plan et laissez la courte tâche se terminer :
echo $! > nohup.pid
sleep 4
cat nohup.log
Vous devez voir trois lignes, de background: one à background: three. Pour une tâche de longue durée, le PID et le journal enregistrés permettent d’en suivre l’avancement.
Inspecter les messages récents du noyau
Dans cette étape, vous allez examiner le tampon de messages du noyau et enregistrer la version du noyau en cours d’exécution comme référence stable.
Le noyau enregistre dans un tampon circulaire des messages concernant le démarrage, le matériel, les pilotes et les événements survenus pendant l’exécution. dmesg lit ce tampon. Des privilèges d’administration sont généralement nécessaires :
cd /home/labex/project/process-lab
sudo dmesg | tail -n 10
Les messages exacts varient selon la machine et le moment. Concentrez-vous sur le champ ressemblant à un horodatage ainsi que sur le composant ou le sous-système à l’origine de chaque message.
L’option --level filtre les messages par niveau de gravité. Affichez les avertissements et les erreurs récents :
sudo dmesg --level=err,warn | tail -n 10
L’absence de sortie ne signifie pas que la commande a échoué ; elle peut simplement indiquer que le tampon actuel ne contient aucun message de ces niveaux. Recherchez dans les messages récents des termes courants liés au stockage et au réseau :
sudo dmesg | grep -Ei 'disk|filesystem|network|eth' | tail -n 10
Là encore, les résultats dépendent du système actuel. Enregistrez la version du noyau renvoyée par uname -r :
uname -r > kernel-version.txt
cat kernel-version.txt
Les messages du noyau sont des éléments d’observation, et non des diagnostics automatiques. Avant de décider d’une action, mettez-les en relation avec l’état des processus, les journaux des services et les symptômes observés.
Résumé
Vous avez identifié un système Linux, interprété la durée de fonctionnement et les charges moyennes, puis inspecté les PID, les processus parents, les propriétaires, les états et l’activité des ressources à l’aide d’outils produisant des instantanés ou un affichage interactif. Vous avez démarré et recherché des processus nommés, les avez ciblés précisément avec kill et pkill, utilisé SIGTERM avant SIGKILL et pratiqué le contrôle des tâches au premier plan et en arrière-plan.
Vous avez également interprété les statuts de sortie, exécuté une tâche détachée avec nohup et une journalisation explicite, puis inspecté les messages du noyau avec dmesg. Ces habitudes fondées d’abord sur l’observation constituent la base d’un dépannage sûr des processus et vous préparent aux diagnostics des services, des journaux et du réseau dans la suite du cours.
