Tronc commun / B1 / Réseaux & systèmes / Gestion des processus & planification

Gestion des processus & planification

Supervision des processus, contrôle par signaux, priorités, services et automatisation.

1. Processus et états

Processus = instance d'un programme en cours d'exécution. Identifié par son PID, il connaît son parent par le PPID. Tout processus descend d'un autre : l'ensemble forme une arborescence dont la racine est systemd (PID 1).

Un zombie ne consomme pas de ressources hormis une entrée dans la table des processus. On ne le tue pas : il disparaît quand son parent lit son code de retour, ou quand ce parent se termine et que systemd adopte l'orphelin.

2. Observer les processus

ps aux                # liste complète, instantané figé
ps aux | grep apache  # filtrer
top                   # vue temps réel, triée par consommation CPU
htop                  # alternative colorée, navigable au clavier et à la souris
pstree                # hiérarchie des processus
pgrep -a sshd         # trouver un PID par nom

Colonnes à retenir dans top : PID, USER, %CPU, %MEM, STAT (l'état vu plus haut) et NI (la priorité).

3. Premier et arrière-plan

sleep 120 &           # lancer en arrière-plan
jobs                  # lister les tâches du shell courant
fg %1                 # ramener la tâche 1 au premier plan
bg %1                 # la relancer en arrière-plan
Ctrl + Z              # suspendre la tâche du premier plan
nohup ./long.sh &     # survit à la fermeture du terminal

Une tâche lancée avec & reste rattachée au terminal : elle est tuée si celui-ci se ferme. nohup, screen ou tmux permettent de s'en affranchir.

4. Signaux et arrêt

kill 1234             # envoie SIGTERM
kill -9 1234          # envoie SIGKILL
killall firefox       # par nom de programme
pkill -u alice        # tous les processus d'un utilisateur

Toujours essayer SIGTERM avant SIGKILL. SIGTERM laisse le processus fermer ses fichiers, vider ses tampons et libérer ses verrous. SIGKILL ne peut pas être intercepté : le processus s'arrête net, ce qui peut corrompre des données. Le kill -9 réflexe est une mauvaise habitude.

5. Priorité (nice)

La valeur nice va de -20 (priorité la plus forte) à 19 (la plus faible). Par défaut un processus démarre à 0. « Nice » se lit comme la gentillesse : plus la valeur est élevée, plus le processus cède volontiers le processeur aux autres.

nice -n 10 ./heavy.sh          # démarrer avec une priorité faible
sudo nice -n -5 ./heavy.sh     # priorité élevée : sudo obligatoire
renice -n 5 -p 1234            # modifier la priorité d'un processus actif

time ./heavy.sh                # mesurer le temps d'exécution

Seul root peut attribuer une valeur négative : sans cette restriction, n'importe quel utilisateur pourrait s'octroyer tout le processeur. En lançant le même script à 0, 10 et -5 puis en comparant les temps mesurés par time, on observe l'écart — d'autant plus net que la machine est chargée.

6. Services et systemd

Les processus qui tournent en permanence en arrière-plan (serveur web, SSH, base de données) sont des services, gérés par systemd.

systemctl status apache2         # état du service
sudo systemctl start apache2     # démarrer
sudo systemctl stop apache2      # arrêter
sudo systemctl restart apache2   # redémarrer
sudo systemctl reload apache2    # recharger la conf sans couper le service
sudo systemctl enable apache2    # démarrage automatique au boot
sudo systemctl disable apache2   # désactiver le démarrage automatique

journalctl -u apache2 -f         # suivre les journaux du service

enable et start sont indépendants : un service peut tourner sans être activé au démarrage, et inversement. Oublier enable est la cause classique du service qui « disparaît » après un redémarrage.

7. Planification

cron — tâches récurrentes

crontab -e            # éditer les tâches de l'utilisateur courant
crontab -l            # les lister
crontab -r            # tout supprimer (attention)

Pour le jour de la semaine, 0 et 7 désignent tous deux le dimanche.

Deux pièges très fréquents :

• Le script doit être exécutable (chmod +x) et référencé par un chemin absolu.
• cron s'exécute avec un environnement minimal : la variable PATH n'est pas celle de la session. Un script qui marche dans le terminal peut échouer en cron. On y déclare les chemins complets, et l'on redirige la sortie vers un fichier pour pouvoir diagnostiquer : 0 2 * * * /home/alice/backup.sh >> /home/alice/cron.log 2>&1

crontab -e gère les tâches d'un utilisateur ; /etc/crontab et /etc/cron.d/ sont les fichiers système, avec un champ supplémentaire indiquant l'utilisateur d'exécution.

at — exécution unique

echo "/home/alice/script.sh" | at 22:00
atq                   # lister les tâches en attente
atrm 3                # supprimer la tâche 3

8. Isolation avec chroot

chroot change la racine apparente du système de fichiers pour un processus : il ne voit plus rien au-dessus du répertoire désigné. C'est l'ancêtre des mécanismes de conteneurisation.

mkdir -p ~/mychroot/{bin,lib,lib64}
cp -r /bin/* ~/mychroot/bin/
cp -r /lib/* ~/mychroot/lib/
cp -r /lib64/* ~/mychroot/lib64/
sudo chroot ~/mychroot /bin/bash

À l'intérieur, seules les commandes copiées fonctionnent : toute autre renvoie « command not found », puisque son binaire est hors de la nouvelle racine.

• Intérêt en sécurité : si un service exposé est compromis, l'attaquant reste enfermé dans l'environnement et n'atteint ni /etc ni /home. Historiquement utilisé pour les serveurs FTP et DNS.
• Autres usages : réparer un système depuis un live CD, compiler dans un environnement contrôlé, tester une distribution différente.
• Limite : ce n'est pas une vraie isolation. Un processus root dans un chroot peut en sortir. Pour une isolation sérieuse, on utilise des conteneurs (namespaces et cgroups) ou des machines virtuelles.