EnglishCommencer

Surveiller et maîtriser les processus

Retrouver, tester, borner et arrêter un processus depuis un script : pgrep, pkill, kill -0, timeout, nice, ulimit, le dossier /proc, le fichier de PID, le démon et le zombie.

  • 32 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • Démon : de quoi s'agit-il ?

    Voir la réponse

    Processus de fond rattaché à aucun terminal, dont le père est le processus 1 : celui qui l'a lancé est parti et le processus 1 l'a adopté.

    Il se détache de son terminal pour survivre à la fermeture de la session. Sous systemd, c'est systemd qui le lance et le supervise : il n'a plus besoin de se détacher lui-même.

  • Qu'affiche ce script ?

    ```bash
    sleep 300 &
    kill -0 $!
    echo $?
    `

    • 0
    • 1
    • 143
    • 124
    Voir la réponse

    0

    $! est le PID de la tâche de fond, qui existe et appartient à l'utilisateur : kill -0 réussit sans rien envoyer. 143 serait le code d'un processus mort de SIGTERM, 124 celui de timeout.

  • La commande kill -0 PID n'envoie aucun signal : elle rend le code … si le processus existe et qu'on a le droit de le signaler, un code non nul sinon.

    Voir la réponse

    La commande kill -0 PID n'envoie aucun signal : elle rend le code 0 si le processus existe et qu'on a le droit de le signaler, un code non nul sinon.

    C'est le test de vie d'un processus. Pour un processus absent, bash répond « kill: (999999) - No such process » et le code vaut 1.

  • Fichier de PID : de quoi s'agit-il ?

    Voir la réponse

    Petit fichier où un service écrit son numéro de processus au démarrage, pour que les scripts puissent le retrouver, le tester ou l'arrêter.

    Il devient périmé si le service plante sans l'effacer, et son numéro peut être réattribué à un autre processus : avant de tuer, on teste kill -0 et on compare /proc/PID/cmdline.

  • Un service journalise « accept: Too many open files » après quelques heures. ls /proc/PID/fd | wc -l donne 1022, et /proc/PID/limits indique « Max open files 1024 ». Quelle est la cause probable et la bonne première réponse ?

    • Le disque est plein : repérer avec df le système de fichiers saturé, puis supprimer les gros fichiers inutiles
    • La mémoire est saturée : ajouter de la mémoire vive à la machine ou réduire le nombre de processus actifs
    • Il touche son plafond de descripteurs : chercher ce qu'il ne ferme pas, puis relever le plafond si la charge le justifie
    • Le port d'écoute est déjà pris par un autre processus : changer son numéro dans la configuration du service
    Voir la réponse

    Il touche son plafond de descripteurs : chercher ce qu'il ne ferme pas, puis relever le plafond si la charge le justifie

    1022 liens dans /proc/PID/fd pour une limite de 1024 : le processus a presque épuisé ses descripteurs. On lit la limite du service dans /proc/PID/limits, car ulimit -n ne donne que celle du shell courant. Relever la limite sans chercher la fuite ne fait que reculer l'échéance.

Réviser ce deck