WIKI Retour au Portfolio

Dernière mise à jour : 23 juin 2026

4 - Administrer les tâches

Gestion des logiciels (RPM/DNF), des processus, des services systemd, de la planification de tâches, du tuning et de la journalisation sous RHEL 9.

ℹ️ Ce module couvre les objectifs EX200 : install/update/manage software packages, identify/manage/kill processes, start/stop/check services, schedule tasks, adjust process scheduling, locate and interpret system log files and journals.


A. Gestion des logiciels (RPM)

  • Les logiciels sont installés via des paquets au format RPM et enregistrés dans la base de données RPM.
  • Un RPM contient : une archive compressée + des métadonnées (où les dépendances sont déclarées).
  • Pour les dépendances, RHEL utilise un dépôt (repository) : une dépendance trouvée s'installe automatiquement depuis le dépôt.
rpm -qa                  # tous les paquets installés
rpm -qf /chemin/fichier  # par quel paquet un fichier a été installé
rpm -ql paquet           # liste tous les fichiers d'un paquet
rpm -q --scripts paquet  # scripts exécutés lors de l'installation
rpm -q --changelog paquet # changelog du paquet
rpm -qp paquet.rpm ...   # -p : interroger un fichier .rpm non installé

Extraction d'un paquet (sans installer)

rpm2cpio paquet.rpm | cpio -tv   # affiche le contenu du paquet
rpm2cpio paquet.rpm | cpio -idmv # extrait le paquet dans le répertoire courant

💡 Utile pour récupérer un seul fichier (ex : un fichier de config supprimé) sans réinstaller le paquet entier.


B. Dépôts de paquets (repositories)

  • Un dépôt est une collection de paquets RPM.
  • Souvent en ligne (via subscription-manager), mais on peut en créer des locaux.
  • dnf est la commande d'installation (remplace l'ancien yum).
dnf config-manager --enable depot          # activer un dépôt offert par l'abonnement
dnf config-manager --add-repo="file:///repo/AppStream"  # ajouter un dépôt tiers
ls /etc/yum.repos.d                        # fichiers de config des dépôts

Création manuelle d'un fichier .repo :

cat >> /etc/yum.repos.d/AppStream.repo <<EOF
[AppStream]
name=AppStream
baseurl=file:///repo/AppStream
gpgcheck=0
EOF

🚨 Sous RHEL 9, dnf config-manager est fourni par le plugin dnf-plugins-core. La syntaxe officielle de l'URL est file:///repo/... (trois slashes : file:// + chemin absolu /repo/...).

Configurer un dépôt local depuis l'ISO

df -h                # il faut ~10 Go libres sur /
lsblk                # repérer sr0 (lecteur optique où l'ISO est monté)
dd if=/dev/sr0 of=/rhel9.iso bs=1M   # copier le disque optique en fichier ISO
mkdir /repo
echo "/rhel9.iso /repo iso9660 defaults 0 0" >> /etc/fstab  # montage à chaque boot
mount -a             # appliquer le montage immédiatement
# Dépôt interne disponible dans /repo :
dnf config-manager --add-repo="file:///repo/BaseOS"
dnf config-manager --add-repo="file:///repo/AppStream"
dnf repolist         # vérifier les dépôts actifs

Signature du dépôt (GPG)

  • Pour garantir que les paquets n'ont pas été altérés, on utilise des clés GPG.
  • Le dépôt signe tous ses paquets ; avant installation, la signature est vérifiée.
  • Dans le fichier .repo client, gpgcheck=1 active la vérification (mettre gpgcheck=0 la désactive — à éviter en production).

C. Gérer les paquets avec DNF

dnf list                       # paquets disponibles
dnf list 'selinux*'            # paquets commençant par selinux
dnf search all seinfo          # cherche aussi dans la description (avec 'all')
dnf provides */Containerfile   # trouve le paquet fournissant un fichier
dnf info paquet                # infos détaillées
dnf install paquet             # installe le paquet + dépendances
dnf remove paquet              # retire le paquet ET ses dépendances (⚠️ dangereux)
dnf update                     # compare et installe les nouvelles versions
dnf update kernel              # met à jour le kernel en GARDANT l'ancien

🚨 dnf remove retire aussi les dépendances devenues orphelines : peut casser d'autres logiciels. dnf update kernel est l'exception qui conserve l'ancienne version (rollback possible).

Groupes de paquets

Un regular group est une collection de paquets ; un environment group est un pattern d'usage (paquets + groupes).

dnf group list                 # liste des groupes
dnf group list hidden          # affiche aussi les groupes cachés
dnf group info "Nom"           # paquets contenus dans un groupe
dnf group install "Nom"        # installe les paquets default + mandatory
dnf group install --with-optional "Nom"  # inclut aussi les paquets optionnels

Modularité et dépôts RHEL 9

  • DNF utilise la modularité : plusieurs versions du même paquet peuvent coexister dans un même dépôt.
  • RHEL 9 a deux dépôts principaux :
    • BaseOS — paquets de base de l'OS (même cycle de vie que l'OS).
    • AppStream — applications et langages (cycle de vie applicatif).

Historique des transactions

cat /var/log/dnf.rpm.log       # log brut des opérations
dnf history                    # résumé des installations / suppressions
dnf history undo <ID>          # annule la transaction <ID>

Subscription Manager

L'utilisation de RHEL nécessite normalement un abonnement.

subscription-manager register          # demande ID + mot de passe Red Hat
subscription-manager attach --auto     # active l'abonnement (certificats créés)
dnf repolist                           # les dépôts deviennent visibles
subscription-manager unregister        # désinscrire le système

Certificats créés : /etc/pki/product (produit Red Hat), /etc/pki/consumer (enregistrement du compte), /etc/pki/entitlement (abonnement attaché).


D. Activité système : jobs et processus

  • Chaque tâche démarre comme un processus avec un PID.
  • Process management : ordonnancement (scheduling), priorité, envoi de signaux.
  • Les tâches lancées depuis le shell sont gérées comme des jobs (premier plan / arrière-plan).

Diagramme conceptuel : tasks → queue → scheduler → cores, avec time slice par tâche

Gérer les jobs du shell

commande &     # lance le job en arrière-plan
# Ctrl+Z puis :
bg             # renvoie le job stoppé en arrière-plan
jobs           # liste les jobs en cours
fg %1          # ramène le job n°1 au premier plan

Cycle de vie d'un processus

  • Nouveau processus créé (fork) → schedulé → état R (runnable).
  • Reçoit un time slice → exécution en kernel space ou user space → peut être preempted / re-schedulé (retour en R, file d'attente).
  • Peut être stoppé (Ctrl+Z) → état T (stopped) → reprend sur signal.

États d'attente (wait states) et flags :

État Nom Signification
R RUNNING / RUNNABLE en exécution ou prêt à l'être
S TASK_INTERRUPTIBLE attend matériel, ressource ou signal
K TASK_KILLABLE attend, mais peut être tué
D TASK_UNINTERRUPTIBLE attend, ne répond pas aux signaux
I TASK_REPORT_IDLE thread kernel inactif (ne compte pas dans le load average)
T TASK_STOPPED stoppé (Ctrl+Z)
Z EXIT_ZOMBIE terminé, statut pas encore collecté par le parent
X EXIT_DEAD nettoyé, processus mort

🚨 Zombie : processus qui a fini sa tâche mais dont le parent n'a pas collecté le statut de sortie. Déjà mort → ne peut pas être killed. Seul problème : il occupe un PID. Solution : tuer le parent, ou lui envoyer le signal SIGCHLD (souvent ignoré). Sinon init/systemd (PID 1) l'adopte et le reap.

La commande ps

ps accepte deux styles d'options : BSD (sans tiret) et System V (avec tiret).

ps aux                       # tous les processus + infos détaillées
ps -fax                      # processus avec relation hiérarchique
ps -fU hamid                 # processus appartenant à hamid
ps -f --forest -C sshd       # arborescence du processus sshd (tous ses enfants)
ps -eo pid,ppid,user,cmd     # champs personnalisés avec les arguments

E. Mémoire et charge CPU

Usage mémoire

  • Linux met beaucoup de fichiers en cache pour un accès rapide → la mémoire paraît souvent saturée (c'est normal).
  • Le swap émule la RAM en cas de débordement ; le kernel y déplace d'abord les applications inactives.

Diagramme conceptuel : application → RAM, cache → drop, pages active/inactive et swap

free -m                # infos mémoire en mégaoctets
less /proc/meminfo     # détails sur la mémoire
sync                   # vide le write cache (buffers) sur disque

💡 Write cache : à l'édition d'un fichier, les écritures passent par les buffers (flush par le kernel). sync force l'écriture sur disque — utile avant une opération risquée pour limiter une perte en cas de crash.

💡 Pour tester le swap : au boot, éditer la ligne GRUB (e) et ajouter mem=1G aux paramètres kernel pour limiter la RAM, puis observer le passage en swap.

Charge CPU (load average)

  • Moyenne du nombre de processus en exécution sur les 1, 5 et 15 dernières minutes.
  • Règle : la valeur ne doit pas dépasser le nombre de cœurs du système.
uptime    # affiche le load average
lscpu     # nombre de cœurs disponibles

Monitorer en temps réel : top

Tableau de bord interactif de l'activité système.

top
# Dans top :
#   f → sélectionner les colonnes affichées
#   M → trier par usage mémoire
#   W → sauvegarder la configuration d'affichage
#   k → envoyer un signal (kill) à un PID
htop      # alternative plus visuelle (non installée par défaut)

Diagnostic rapide : comparer le load average (top/uptime) au nombre de cœurs (lscpu).


F. Gérer les processus : signaux et priorités

Signaux et kill

kill <PID>                 # envoie SIGTERM au PID (terminaison propre)
killall nom                # tue les processus par leur nom
kill -9 <PID>              # SIGKILL : coupe immédiatement (⚠️ risque de corruption)
man 7 signal               # liste des signaux

Réaper un zombie :

ps aux | grep zombie       # noter les PID enfant et parent
ps fax                     # voir le zombie et ses parents (arborescence)
kill <childpid>            # échoue (zombie déjà mort)
kill -SIGCHLD <parentpid>  # souvent ignoré
kill <parentpid>           # le zombie est adopté par init et reapé en quelques secondes

🚨 Signaux les plus utilisés : SIGTERM (15, terminaison propre, par défaut) et SIGKILL (9, terminaison forcée non interceptable). Privilégier SIGTERM ; SIGKILL en dernier recours. SIGHUP (1) demande à un daemon de recharger sa configuration.

Priorités (nice / renice)

  • Cgroups : le système est divisé en 3 slicessystem, user, machine (VM/conteneurs). Chaque slice reçoit un CPU équivalent (20 processus systemd ≈ autant de CPU qu'1 processus utilisateur). Réglable via CPUWeight dans systemd.
  • nice/renice changent la priorité (sauf processus realtime).
  • Valeur niceness : de -20 (plus haute priorité) à 19 (plus basse).
nice -n 19 dd if=/dev/zero of=/dev/null   # lancer avec faible priorité
renice -n 5 -p <PID>                       # changer la priorité d'un processus existant

⚠️ Non couvert par les notes : seul root peut baisser la valeur niceness (augmenter la priorité, valeurs négatives) ; un utilisateur standard ne peut que l'augmenter (baisser la priorité).

Autres : processus par utilisateur

ps -u user                 # processus d'un utilisateur
pkill -u user              # tuer tous les processus d'un utilisateur
loginctl                   # gestion systemd des users/sessions
loginctl list-users        # liste des utilisateurs connectés
loginctl list-sessions     # liste des sessions
loginctl user-status <UID> # arborescence des processus d'un user
loginctl terminate-session <ID>  # fermer une session
loginctl terminate-user <UID>    # fermer toutes les sessions d'un user

G. System Tuning (tuned)

Le tuning améliore le rendement selon la charge de travail, via des profils.

Kernel tunables (/proc/sys)

echo 40 > /proc/sys/vm/swappiness   # writable mais NON persistant (perdu au reboot)

Persistance via /etc/sysctl.d/ :

echo "vm.swappiness = 33" > /etc/sysctl.d/swappiness.conf
sysctl -a | grep swappi             # encore l'ancienne valeur
sysctl -p /etc/sysctl.d/swappiness.conf   # charge les changements
sysctl -a | grep swappi             # désormais à 33

Profils tuned

dnf install tuned                   # installer tuned si absent
tuned-adm list                      # liste des profils + profil actif
tuned-adm active                    # profil actuellement actif
tuned-adm profile virtual-guest     # définir un profil
  • Chaque profil possède un tuned.conf dans /etc/tuned/<profil>/ (ou /usr/lib/tuned/).
  • Fichier principal : /etc/tuned/tuned-main.conf.

Exemple : créer un profil personnalisé

mkdir /etc/tuned/monprofil
cat >> /etc/tuned/monprofil/tuned.conf <<EOF
[sysctl]
vm.swappiness=66
EOF
tuned-adm profile monprofil
sysctl -a | grep swappi             # peut ne pas montrer 66 si reapply désactivé
vi /etc/tuned/tuned-main.conf       # mettre reapply_sysctl=0 selon le comportement voulu

H. Planification de tâches (task scheduling)

Trois mécanismes :

  • systemd timers — solution principale recommandée sous RHEL 9.
  • crond — solution historique, plus simple.
  • at — tâche unique non récurrente.

Systemd timers

  • Un fichier unit.timer est relié à un unit.service pour le planifier.
  • On gère le timer (pas le service) : il doit être enabled et started.
systemctl list-units --type timer            # timers actifs
systemctl list-unit-files 'logrotate.*'      # service + timer de logrotate
systemctl status logrotate.service           # inactif, déclenché par le timer
systemctl status logrotate.timer             # actif, en attente
dnf install -y sysstat
systemctl cat sysstat-collect.timer          # voir la config du timer

Configuration via la directive OnCalendar :

[Timer]
OnCalendar=*:00/10
# *:00/10                          → toutes les 10 minutes
# 2023-*-* 9:09,19,29:30           → chaque jour en 2023 à 9h09:30, 9h19:30, 9h29:30

Autres directives :

  • OnUnitActiveSec= — déclenche un délai après activation de l'unité.
  • OnBootSec= / OnStartupSec= — déclenche un délai après le boot / le démarrage de systemd.
man 7 systemd.time      # syntaxe complète des calendriers

Exemple : service oneshot + timer (création d'un fichier toutes les minutes)

Création des unités touchfile.service (Type=oneshot, ExecStart=touch) et touchfile.timer (OnCalendar=*:00/01) via cat >> EOF

Commandes systemctl : daemon-reload, start du timer, status du service, watch sur le fichier créé, stop du timer

💡 Pour qu'un timer survive au reboot : systemctl enable touchfile.timer.

Cron

  • Le service crond vérifie ses fichiers de config chaque minute.
Emplacement Rôle
/etc/crontab fichier de configuration principal (ne pas éditer)
/etc/cron.d/ drop-in files
/etc/cron.{hourly,daily,weekly,monthly} scripts exécutés périodiquement
crontab -e     # éditer le crontab de l'utilisateur courant
crontab -l     # lister

Format d'une ligne cron : minute heure jour-du-mois mois jour-de-semaine commande

0 * * dec 1-5 commande   # à la minute 0 de chaque heure, lun→ven, en décembre
10 * * * * logger HELLO  # à la minute 10 de chaque heure, tous les jours

🚨 Ne pas éditer /etc/crontab directement : utiliser des drop-in files dans /etc/cron.d/. Exemples de syntaxe disponibles dans /etc/crontab.

Anacron

  • Service derrière cron : exécute les jobs on a daily basis sans heure précise garantie (rattrape les exécutions manquées si la machine était éteinte).
  • Jobs dans /etc/cron.{hourly,daily,weekly,monthly}.
  • Fichier de config : /etc/anacrontab.

💡 Pour une tâche périodique sans contrainte d'horaire exact : anacron suffit, mais les systemd timers sont préférés sous RHEL 9.

Le service at (tâche unique)

systemctl status atd       # le service atd doit tourner
at <time>                  # saisir la commande puis Ctrl+D pour valider
atq                        # lister les jobs planifiés
atrm <numéro>              # supprimer un job (numéro visible dans atq)

Gestion du temps (timedatectl)

La planification dépend d'une horloge correcte : fuseau horaire et synchronisation NTP.

timedatectl                              # état date/heure/fuseau/NTP
timedatectl set-timezone Europe/Paris    # changer le fuseau horaire
timedatectl set-ntp true                 # activer la synchro NTP (service chronyd)

I. Fichiers temporaires (systemd-tmpfiles)

  • Avant : les temporaires de /tmp pouvaient persister très longtemps.
  • Désormais /tmp peut être sur un RAM drive (nettoyé à chaque redémarrage).
  • systemd-tmpfiles démarre au boot et crée/supprime automatiquement les fichiers temporaires selon ses fichiers de config.
Emplacement Rôle
/usr/lib/tmpfiles.d/ config fournie par les paquets RPM
/etc/tmpfiles.d/ config administrateur (la nôtre)
/run/tmpfiles.d/ config générée par le système
systemd-tmpfiles --create <conf>   # crée les fichiers/dossiers définis
systemd-tmpfiles --clean <conf>    # supprime ceux dont l'âge dépasse la durée
# Unités associées :
#   systemd-tmpfiles-setup.service  → création au boot
#   systemd-tmpfiles-clean.timer    → appelle clean.service pour le nettoyage

Format d'une ligne de config : Type Chemin Mode Propriétaire Groupe Âge.

Types tmpfiles.d : ligne d (crée le dossier, aucune action s'il existe) vs D (crée et vide le contenu, supprime les fichiers de plus d'1 jour), et man tmpfiles.d

Exemple complet

Première partie de l'exemple tmpfiles.d : config q /tmp 7d et --clean, puis config d /tmp/myfiles 30s avec --create et touch du fichier test

Seconde partie de l'exemple tmpfiles.d : ls du fichier test, sleep 30, ls à nouveau, puis --clean qui supprime test (âge dépassé)


J. Services systemd

systemd est le premier processus (PID 1) lancé après le chargement du kernel ; il gère tout le système.

  • Démarre les services (SSH, serveur web, etc.).
  • systemctl est l'outil de gestion principal.

Types d'unités :

Unité Rôle
.service démarre un processus / daemon
.socket surveille un port → démarre le service correspondant
.timer démarre un service périodiquement
.path démarre un service quand une activité fichier est détectée
.mount monte un système de fichiers

💡 Type=oneshot permet de lancer n'importe quelle commande unique via systemd.

systemctl -t help                  # types d'unités disponibles
systemctl list-units               # unités chargées
systemctl list-units -t timer      # uniquement les timers
systemctl list-unit-files          # toutes les unités et leur état
systemctl status <unit>            # état d'une unité + derniers logs
systemctl start <unit>
systemctl stop <unit>
systemctl enable <unit>            # démarrage automatique au boot
systemctl disable <unit>
systemctl reload <unit>            # recharge la config sans redémarrer le service
systemctl restart <unit>           # redémarre (nouveau PID)
systemctl enable --now <unit>      # active au boot + démarre en une fois
systemctl list-units --type=service  # unités de type service
État systemd Sens
active (running) en cours d'exécution
inactive (dead) arrêté
enabled démarre au boot
disabled ne démarre pas au boot
failed a échoué

Targets (cibles de démarrage)

systemctl get-default                      # cible (target) par défaut
systemctl set-default multi-user.target    # mode texte (vs graphical.target = mode graphique)

Modifier la config d'une unité

Emplacement Rôle
/usr/lib/systemd/system unités fournies par les paquets (ne pas modifier)
/etc/systemd/system unités custom / surcharges (priorité la plus haute)
/run/systemd unités runtime
systemctl edit <unit>          # crée un drop-in de surcharge dans /etc/systemd/system
systemctl show <unit>          # paramètres effectifs actuels
systemctl daemon-reload        # recharger après modification manuelle d'un fichier

Exemple : redémarrage auto d'un service défaillant (via systemctl edit) :

[Service]
Restart=always
RestartSec=5s

Dépendances

systemctl list-dependencies          # vue d'ensemble
systemctl list-dependencies <unit>   # dépendances d'une unité

💡 Au troubleshooting : un service down peut l'être à cause d'une dépendance down.

Masquer une unité

  • Empêche totalement le démarrage d'une unité (lien symbolique vers /dev/null).
systemctl mask <unit>      # lie l'unité à /dev/null → impossible à démarrer
systemctl unmask <unit>    # annule le masquage

K. Journalisation (logging)

Deux mécanismes principaux sous RHEL :

  • systemd-journald — reçoit les logs du kernel, de l'early boot, des événements syslog, et de la sortie standard/erreur des daemons. Non persistant par défaut.
  • rsyslog — service qui lit les messages syslog et les écrit dans /var/log (et autres destinations).

Diagramme : journald reçoit service/kernel/early boot ; forward vers rsyslog ; /etc/rsyslog.conf → fichiers /var/log et DB selon facility

systemd-journald

systemctl status <unit>            # derniers messages du journal pour un service
journalctl                         # journal complet (messages importants en rouge)
journalctl -p err                  # priorité error et supérieures uniquement
journalctl -f                      # suit les nouveaux messages en temps réel
journalctl -u sshd.service         # journal d'un service précis
journalctl --since "-1 hour"       # depuis 1 heure
journalctl --since today           # depuis aujourd'hui
journalctl -o verbose              # sortie détaillée (tous les champs)
journalctl -b                      # log du boot courant
journalctl -xb                     # idem avec explications enrichies
journalctl --list-boots            # liste des boots (journal persistant requis)
journalctl -b -3                   # messages du 3e boot précédent

Rendre le journal persistant

Journald forwarde ses messages à rsyslog, mais on peut aussi le rendre persistant :

grep 'Storage=' /etc/systemd/journald.conf
mkdir /var/log/journal             # le simple fait de créer ce dossier active la persistance
systemctl restart systemd-journald
ls /var/log/journal

Options de la directive Storage= dans /etc/systemd/journald.conf :

Valeur Effet
auto persistant si /var/log/journal existe, sinon volatile
persistent stocke dans /var/log/journal (crée le dossier si besoin)
volatile stocke uniquement dans /run/log/journal (RAM, perdu au reboot)
none aucun stockage

🚨 Sans persistance, les logs sont en mémoire et perdus au reboot. Le fichier de config est journald.conf (et non journal.conf).

Taille du journal (politiques dans journald.conf) :

  • rotation déclenchée mensuellement,
  • pas plus de ~10 % du filesystem utilisé,
  • au moins ~15 % d'espace libre conservé.

Configurer rsyslog

  • Service : rsyslogd. Config : /etc/rsyslog.conf + drop-in dans /etc/rsyslog.d/.
  • Chaque règle comporte 3 éléments :
    • facility — la catégorie qui génère le log,
    • severity — le niveau de gravité,
    • destination — fichier (ou autre) où écrire le log.
logger "message de test"           # écrire manuellement dans rsyslog
logger --help

Exemple de règle dans la config (envoyer les erreurs vers un fichier dédié) :

*.err   /var/log/error.log         # toutes les facilities, severity err et + → fichier
systemctl restart rsyslog.service  # appliquer

Logrotate

  • Limite la taille des fichiers de log (rôle de logrotate).
  • Après rotation, le fichier est renommé avec la date en extension ; les plus anciens sont supprimés au-delà de la limite.
  • Config : /etc/logrotate.conf + /etc/logrotate.d/.
  • logrotate est déclenché par un systemd timer (logrotate.timer).
systemctl list-unit-files -t timer   # voir logrotate.timer
systemctl cat logrotate.service
vim /etc/logrotate.conf              # rotations globales, seuils de suppression

Exemple de fichier dans /etc/logrotate.d/error pour /var/log/error.log :

/var/log/error.log {
    monthly
    create
    rotate 5
    dateext
}

⚠️ Non couvert par les notes (objectif EX200 connexe) : preserve system journals to persistent storage est testé — la création de /var/log/journal (section K) est le geste attendu.