Introduction
Un système Linux en fonctionnement ne se résume pas à ses fichiers. Le noyau gère le matériel et les processus, chaque commande s’exécute sous la forme d’un processus doté d’un identifiant, et l’interpréteur de commandes suit les tâches exécutées au premier plan ou en arrière-plan. Pour administrer un système, on commence par observer cet état avant d’agir sur le processus strictement nécessaire.
Dans ce laboratoire, vous apprendrez à identifier le système d’exploitation et le noyau, à interpréter la durée de fonctionnement et les moyennes de charge, à examiner les relations entre les processus, à trouver des processus par leur nom, à envoyer des signaux d’arrêt, à manipuler interactivement les tâches, à interpréter les codes de sortie, à exécuter une commande détachée avec nohup et à consulter les messages récents du noyau.
Identifier le système et interpréter la charge
Dans cette étape, vous identifierez le noyau et la distribution, vérifierez depuis combien de temps le système fonctionne et découvrirez ce que représentent les moyennes de charge.
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 fournit 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. Consultez les métadonnées de la distribution :
cat /etc/os-release
Recherchez 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 moyennes de charge. Ces moyennes décrivent le volume de travail exécutable ou non interruptible sur environ 1, 5 et 15 minutes. Il ne s’agit pas de pourcentages : leur interprétation 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 moyennes de charge. Les champs suivants indiquent les tâches exécutables et l’identifiant de processus attribué le plus récemment.
Enregistrez un bref résumé du système pour pouvoir le consulter ultérieurement :
uname -srm > system-summary.txt
uptime >> system-summary.txt
cat system-summary.txt
Le fichier doit contenir une ligne décrivant le noyau et une ligne indiquant la durée de fonctionnement.
Examiner les processus et l’activité des ressources
Dans cette étape, vous examinerez les identifiants des processus, leurs relations parentales, leurs états ainsi qu’un aperçu de l’activité des ressources système.
Un processus est un programme en cours d’exécution. Chaque processus possède un identifiant de processus, ou PID. La plupart possèdent également un identifiant de processus parent, ou PPID, qui désigne le processus à l’origine de leur lancement.
La commande ps affiche un instantané des processus. Sélectionnez les 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.STATindique l’état du processus ainsi que d’éventuels indicateurs supplémentaires.COMMANDest le nom de l’exécutable.
Les principales lettres d’état sont notamment R pour 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 généralement simplement de recevoir du travail.
La forme ps aux, issue de la syntaxe BSD, fournit les colonnes relatives au processeur et à la mémoire, ainsi que les lignes de commande complètes :
ps aux | head -n 10
Utilisée en mode interactif, top se met à jour en continu. Le mode par lots permet d’obtenir un instantané stable : -b active la sortie par lots et -n 1 demande une seule mise à jour.
top -b -n 1 | head -n 12
L’en-tête récapitule la durée de fonctionnement, la charge, l’état des tâches, l’utilisation du processeur et la mémoire. Le tableau des processus qui suit permet de repérer ceux qui consomment activement des ressources.
Ouvrez maintenant l’affichage interactif :
top
Observez l’actualisation 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 dans le temps ; le mode batch convient mieux lorsque la sortie doit être enregistrée ou traitée par une autre commande.
Enregistrez un instantané ciblé des processus comme résultat exploitable :
ps -eo pid,ppid,user,stat,comm --sort=pid > process-snapshot.txt
head -n 5 process-snapshot.txt
Lancer et localiser un processus d’exercice
Dans cette étape, vous lancerez un processus inoffensif en arrière-plan, récupérerez son PID et le localiserez avec ps et pgrep.
Le & placé à la fin demande à l’interpréteur de commandes d’exécuter la commande en arrière-plan et de rendre immédiatement la main. Lancez un processus sleep de cinq minutes sous le nom visible labex-worker :
cd /home/labex/project/process-lab
bash -c 'exec -a labex-worker sleep 300' &
La valeur spéciale $! contient le PID du dernier processus lancé en arrière-plan. Enregistrez-la avant de lancer une autre commande en arrière-plan :
worker_pid=$!
echo "$worker_pid" > worker.pid
Examinez 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 écoulée depuis le lancement, tandis que ARGS inclut le nom visible du processus. Utilisez pgrep -f pour rechercher la ligne de commande complète ; -a l’affiche également :
pgrep -af labex-worker
Le PID renvoyé par pgrep doit correspondre à celui enregistré dans worker.pid. Une recherche fondée sur un motif précis est plus sûre que d’intervenir sur tous les processus correspondant à un nom trop général.
Arrêter des processus avec des signaux
Dans cette étape, vous demanderez un arrêt progressif avec SIGTERM et n’utiliserez SIGKILL que sur 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"
Lancez 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 au nouveau shell un instant pour installer son gestionnaire de signal :
sleep 1
Envoyez SIGTERM, attendez brièvement, puis examinez le processus :
kill -TERM "$stubborn_pid"
sleep 1
ps -o pid,stat,args -p "$stubborn_pid"
Il devrait 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 progressif reste sans effet :
kill -KILL "$stubborn_pid"
Récupérez la tâche d’arrière-plan terminée. Le code 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 doit donc rester une solution de dernier recours.
kill cible un PID connu. Lorsque vous devez sélectionner un processus par son nom ou sa ligne de commande complète, pkill combine la recherche et l’envoi du signal. Lancez 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 ; un motif trop large peut 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 suspendrez une commande exécutée au premier plan, la reprendrez en arrière-plan, la ramènerez au premier plan, puis l’interromprez.
Le contrôle des tâches concerne l’interpréteur de commandes interactif actuel. Lancez un processus sleep au premier plan avec un nom facilement 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. L’interpréteur envoie un signal d’arrêt et rend la main.
Affichez les tâches connues de cet interpréteur. L’option -l inclut l’identifiant du processus :
jobs -l
Vous devriez voir une tâche Stopped. Reprenez la tâche numéro 1 en arrière-plan :
bg %1
jobs -l
Son état devrait maintenant être Running, tandis que 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 devrait 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 loin, vous utiliserez nohup pour les tâches qui ne doivent pas dépendre de la session du terminal.
Lire le code de sortie et exécuter une tâche détachée
Dans cette étape, vous interpréterez le code de sortie d’une commande et exécuterez une courte tâche en arrière-plan dont la sortie restera disponible indépendamment de l’affichage du terminal.
Chaque commande renvoie un code entier. Zéro signifie que l’exécution a réussi ; une valeur différente de zéro indique un type d’échec. La variable d’interpréteur $? contient le code de la commande qui vient de se terminer.
Exécutez une commande réussie, puis affichez immédiatement son code :
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 le chemin indiqué :
ls missing-path
Enregistrez son code avant qu’une autre commande ne remplace $? :
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 en sorte qu’un programme ignore le signal de déconnexion du terminal. Le & final le lance 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 dans 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 du processus en arrière-plan et laissez la courte tâche se terminer :
echo $! > nohup.pid
sleep 4
cat nohup.log
Vous devriez voir trois lignes, de background: one à background: three. Pour les tâches de longue durée, le PID enregistré et le journal permettent de suivre leur progression.
Examiner les messages récents du noyau
Dans cette étape, vous examinerez le tampon de messages du noyau et enregistrerez 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 permet de lire 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 selon leur gravité. Affichez les avertissements et 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 fournie par uname -r :
uname -r > kernel-version.txt
cat kernel-version.txt
Les messages du noyau constituent des éléments de preuve, 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 moyennes de charge, puis examiné les PID, les processus parents, les propriétaires, les états et les instantanés d’utilisation des ressources. Vous avez lancé et trouvé un processus nommé, 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 codes de sortie, exécuté une tâche détachée avec nohup et une journalisation explicite, puis examiné 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 abordés plus loin dans le cours.
