Cours Linux / Examiner, suspendre et terminer les processus avec ps, top et kill

Pour gérer un processus Linux, identifiez d’abord son PID et sa commande, observez son état, puis envoyez un signal seulement si le besoin et la cible sont clairs. ps fournit un instantané, top une vue actualisée ; STOP suspend, CONT reprend et TERM demande une terminaison que le programme peut traiter. KILL ne laisse pas au programme la possibilité de gérer lui-même ce signal et reste un dernier recours.

Cette leçon utilise Bash et les outils ps, top et pgrep de procps-ng sous Linux. Un ps de Cygwin, une version BusyBox ou un environnement minimal ne fournit pas nécessairement les mêmes colonnes et options. L’expérience de signaux se limite à un nouveau sleep de votre compte, sans sudo ni action sur un service ou sur le processus d’un autre utilisateur.

Distinguer processus, parent, tâche et service

Un processus est une instance de programme en cours d’exécution. Son PID, Process ID, est son identifiant ; son PPID, Parent Process ID, désigne son parent actuel. Un PPID peut changer, notamment lors d’une réattribution du parent. Pour les détails de réattribution, de zombies et d’espaces de noms, le complément PID et PPID, actuellement en anglais traite ces situations séparément.

Une tâche du shell, ou job, est l’unité suivie par un shell pour contrôler une commande ou un pipeline. Une tâche peut contenir plusieurs processus. Un identifiant de tâche comme %1 a un sens dans ce shell ; il n’est pas interchangeable avec un PID numérique.

Un service peut lancer des processus, mais tous les processus ne sont pas des services. Pour un programme géré par un gestionnaire de services, examinez son état et ses journaux avant d’agir sur un PID isolé : le gestionnaire peut le relancer ou gérer plusieurs processus. Notre pratique reste indépendante de ces services.

Choisir les colonnes utiles avec ps

ps lit les informations disponibles au moment de la consultation. Les options suivantes de procps-ng demandent une vue large et des colonnes explicites :

ps -eo pid,ppid,user,stat,etime,args
ps -eo pid,ppid,user,%cpu,%mem,stat,args --sort=-%cpu | head

PID et PPID donnent les identifiants, USER l’utilisateur affiché, STAT l’état et ses indicateurs, ETIME le temps écoulé depuis le lancement et ARGS la ligne de commande disponible. La seconde commande trie par %CPU décroissant puis n’affiche que le début.

Avec ce ps, %CPU est rapporté à la durée de vie du processus : ce n’est pas nécessairement la même mesure qu’un intervalle de top. Une seule ligne ne démontre pas une consommation durable ni une panne. Le manuel procps-ng de ps définit les colonnes, le tri et les états.

Il existe d’autres états et des lettres supplémentaires. Un processus en S ne « tourne » pas forcément en consommant du CPU ; un Z n’est plus un programme actif à tuer pour lui faire terminer son travail. Interprétez l’état avec le contexte de la commande et du parent.

Observer les changements avec top et chercher avec pgrep

top

top actualise l’affichage. Les colonnes, le tri et certains réglages peuvent avoir été personnalisés ; q quitte normalement cette interface. Regardez plusieurs mises à jour lorsque vous cherchez une tendance, plutôt que de conclure d’après une seule valeur. Le manuel de top explique ses vues et commandes interactives.

Pour chercher les PID dont le nom de processus est exactement sleep, avec leur ligne de commande :

pgrep -a -x sleep

-a affiche la ligne de commande, -x demande une correspondance exacte du nom utilisé pour la recherche. Plusieurs sleep peuvent apparaître ; aucune correspondance est également un résultat possible. pgrep n’a pas envoyé de signal et son résultat ne prouve pas que vous devez arrêter ces processus. Le manuel de pgrep précise les critères.

Un processus peut se terminer après la consultation, et un PID peut ensuite être réutilisé. Pour l’expérience suivante, utilisez seulement le PID que votre propre shell vient d’enregistrer, vérifiez sa commande et poursuivez dans ce même shell. Ne choisissez pas au hasard un numéro de la liste globale.

Créer son propre processus de pratique

Lancez un nouveau sleep de 300 secondes en arrière-plan. L’opérateur & rend la main et $! fournit le PID du processus lancé. La variable de cette expérience ne doit jamais être remplacée par un numéro d’un autre programme :

sleep 300 &
processus_pratique=$!
printf 'PID de pratique : %s\n' "$processus_pratique"
ps -p "$processus_pratique" -o pid,ppid,stat,etime,args

La ligne doit montrer votre sleep 300 et son PID ; l’état est normalement une attente comme S. Le nombre exact et le temps écoulé varient. Si le processus a déjà terminé ou si la commande ne correspond pas, ne continuez pas les signaux avec ce numéro : reprenez depuis le lancement d’un nouveau sleep personnel.

Gardez le terminal ouvert et réalisez les étapes sans laisser expirer la durée. Les commandes suivantes testent que la variable n’est pas vide ; ce garde ne vérifie pas à lui seul l’identité du processus, d’où l’importance de la consultation précédente.

Suspendre avec STOP puis reprendre avec CONT

Envoyez STOP uniquement à ce PID et relisez l’état :

test -n "$processus_pratique" && kill -STOP "$processus_pratique"
test -n "$processus_pratique" && ps -p "$processus_pratique" -o pid,stat,args

Vous devez normalement voir T au début de l’état après la suspension. STOP arrête l’exécution sans terminer le processus : son PID peut toujours apparaître. Si la mise à jour n’est pas encore visible, relisez l’état après la prise en compte du signal.

Reprenez le même processus :

test -n "$processus_pratique" && kill -CONT "$processus_pratique"
test -n "$processus_pratique" && ps -p "$processus_pratique" -o pid,stat,args

Le processus redevient exécutable et peut retrouver une attente S ; l’état exact dépend de l’instant d’observation. CONT reprend un processus arrêté, sans recréer une nouvelle instance. Faites cette reprise avant de passer à la terminaison, afin de ne pas laisser votre expérience suspendue.

Linux ne permet pas au programme de capturer, bloquer ou ignorer SIGSTOP, tout comme SIGKILL. Ce n’est pas une garantie d’arrêt immédiat dans toutes les situations noyau : un processus en attente non interruptible peut ne pas réagir tout de suite. La documentation Linux des signaux décrit leurs actions et possibilités de traitement.

Demander la terminaison avec TERM et récupérer l’état

TERM est une demande de terminaison que le programme peut gérer, par exemple pour fermer proprement ses ressources. Le comportement dépend du programme : TERM peut être ignoré ou traité différemment ; il ne garantit pas à lui seul que toutes les données ont été enregistrées. Notre sleep personnel doit normalement se terminer sur ce signal.

if test -n "$processus_pratique"; then
  kill -TERM "$processus_pratique"
  wait "$processus_pratique"
  etat_attente=$?
  printf 'Etat recupere : %s\n' "$etat_attente"
  ps -p "$processus_pratique" -o pid,stat,args
fi

wait attend cet enfant du shell et récupère son état. Une terminaison par signal produit normalement un état non nul ; n’attendez donc pas systématiquement 0. Le dernier ps ne doit plus montrer la ligne de ce sleep ; un en-tête seul ou un état de commande sans processus correspondant est attendu. Contrôlez le résultat sans réutiliser plus tard ce PID comme s’il appartenait encore à l’expérience.

Ces commandes sont prévues dans une session Bash interactive ordinaire. Dans un script qui active set -e, wait peut interrompre l’exécution avant la capture si vous ne traitez pas explicitement son état ; le cours sur les états, les conditions et wait dans Bash permet d’adapter cette logique.

KILL empêche le programme de gérer ce signal ou d’effectuer son propre nettoyage. Sur une base de données ou un service en écriture, une interruption brutale peut laisser un état nécessitant une récupération. L’expérience n’a besoin d’aucun KILL : lorsqu’une application réelle ne termine pas sur TERM, examinez son état, ses journaux, ses dépendances et son gestionnaire avant de choisir une action supplémentaire.

Un utilisateur ordinaire ne peut pas envoyer arbitrairement des signaux aux processus d’autrui ; les règles d’identité et de capacités s’appliquent. Ajouter une élévation de privilèges pour contourner un refus ne remplace pas l’identification du bon programme et du besoin autorisé.

Comprendre le premier plan et les tâches du shell

jobs -l

jobs -l montre les tâches que ce Bash suit, avec leurs numéros et PID. Après wait, le sleep précédent n’a normalement plus de tâche active. Cette liste n’est ni celle d’un autre terminal, ni celle de tout le système.

Dans un Bash interactif avec contrôle des tâches, un processus lancé au premier plan peut recevoir la demande de suspension Ctrl+Z. jobs permet alors de relever le numéro réellement attribué. bg suivi de ce numéro sous la forme %N le reprend à l’arrière-plan ; fg %N le ramène au premier plan. Remplacez N par le numéro observé, sans supposer qu’il vaut toujours 1.

Ces commandes ne donnent pas les mêmes effets qu’un nouveau lancement. fg attend la tâche au premier plan, tandis que bg rend l’invite après l’avoir reprise. Ctrl+C au premier plan demande normalement une interruption au groupe concerné. Le manuel Bash de jobs, bg, fg, kill et wait définit ces opérations.

Une tâche en arrière-plan reste liée à son contexte de session, ses flux et ses signaux. Lancer avec & ne transforme pas une commande en service durable et ne garantit pas sa survie à la fermeture du terminal ou à la déconnexion.

Décider d’une action à partir du contexte

1. Relevez le PID, le parent, l’utilisateur et la commande. Un nom seul peut correspondre à plusieurs instances.
2. Observez l’état et la consommation sur plusieurs consultations ; distinguez une attente normale, un arrêt et une consommation persistante.
3. Déterminez si un service ou un autre gestionnaire pilote le programme, et lisez les journaux pertinents.
4. Si vous devez arrêter votre propre processus, demandez la terminaison appropriée et laissez le temps à son traitement. Ne confondez pas suspendre et terminer.
5. Vérifiez la disparition ou le redémarrage de l’instance, puis cherchez la cause si le symptôme revient.

Le but de la consultation est de choisir une action sur une instance identifiée, pas de supprimer tout ce dont le nom ressemble à un résultat de recherche. Dans cette leçon, le cycle sleep → STOP → CONT → TERM → wait permet de comprendre les opérations sur un seul processus créé pour l’exercice.