Kernel modules & sysctl Linux : réglages noyau pour le DevOps

À la fin de ce tutoriel, vous saurez inventaireer les modules noyau (lsmod, modinfo), charger/décharger un module lab avec modprobe / rmmod, persister le chargement via /etc/modules-load.d/, lire et modifier des paramètres sysctl (/proc/sys/, sysctl -w, /etc/sysctl.d/), et appliquer des réglages DevOps prudents (vm.swappiness, fs.inotify.max_user_watches, net.ipv4.ip_forward) — sur VM jetable, sans prod.

Niveau : Intermédiaire · Temps estimé : 45–55 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11

Slug proposé : linux-kernel-sysctl · Série : Linux Admin · Remplace / fusionne : N/A — création (chapitre 9)

Prérequis

• Hub Linux Admin ; Bases utiles : processus & systemd, processus avancés
• VM ou WSL jetable (Ubuntu/Debian ou Rocky/Alma 9) — pas un hôte de prod ni un nœud partagé
• Compte non-root avec sudo ; aucun secret ; notez les valeurs sysctl d’origine avant de les changer
• Comprendre que modprobe / sysctl -w touchent le noyau en cours : un mauvais module ou une valeur extrême peut figer le lab

Coût estimé : 0 €. Snapshot / checkpoint VM recommandé avant les labs modprobe et sysctl -w.

Ce que nous allons construire

uname -r + arborescence /lib/modules
  → Inventaire : lsmod, modinfo, /proc/modules
  → Lab modprobe / rmmod (module sûr, ex. dummy ou loop)
  → Persist modules-load.d + blacklist modprobe.d
  → sysctl : lecture /proc/sys, sysctl -w, sysctl.d
  → Cas DevOps : swappiness, inotify, ip_forward (lab)
  → Vérification + restauration des valeurs d’origine

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Kernel Linux : modules (lsmod, modprobe, modules-load.d) et sysctl (/proc/sys, sysctl.d) ».)

Neuvième chapitre de Linux Admin. On touche le noyau vivant sans le recompiler : modules (chargés à la demande) et sysctl (knobs runtime). Analogie : module ≈ feature flag ; sysctl ≈ réglages instance.

Étape 1 — Version noyau et arborescence modules

Le noyau en cours a une version unique ; les modules compilés pour cette version vivent sous /lib/modules/$(uname -r)/.

Élément	Commande / chemin	Rôle
Version	uname -r	Répertoire modules
Arborescence	/lib/modules/$(uname -r)/	.ko / .ko.xz
Dépendances	modules.dep	Résolu par modprobe
Chargés	/proc/modules	Vue runtime

uname -r
uname -a
ls /lib/modules/"$(uname -r)" | head
ls /lib/modules/"$(uname -r)"/kernel | head
wc -l /lib/modules/"$(uname -r)"/modules.dep

Rocky/Alma 9 : mêmes chemins. Après update noyau, redémarrez avant modprobe (mismatch modules.dep). Pas de module out-of-tree ici — uniquement le distro.

Étape 2 — Inventaire : lsmod, modinfo, /proc/modules

lsmod liste les modules chargés (nom, taille, usage count, dépendants). modinfo décrit un module sans le charger (licence, paramètres, chemin du .ko).

lsmod | head -n 25
lsmod | wc -l
modinfo loop 2>/dev/null | head -n 20
modinfo dummy 2>/dev/null | head -n 20 || echo "module dummy absent sur cette image — on adaptera le lab"
head -n 5 /proc/modules

Outil	Effet	Prudence
lsmod	Liste chargés	Lecture seule
modinfo NOM	Métadonnées (sans charger)	Lecture seule
/proc/modules	Vue brute	Lecture seule

Un Used by élevé : dépendants actifs — ne rmmod jamais stockage / NIC de votre SSH (ext4, drivers réseau).

Étape 3 — Lab modprobe / rmmod (module sûr)

On charge un module inoffensif pour le lab. Priorité : dummy (interface réseau virtuelle) ou loop (déjà souvent chargé). Vérifiez d’abord avec modinfo et lsmod.

# Choisir une cible lab : dummy si dispo, sinon documenter loop déjà présent
TARGET=""
if modinfo dummy &>/dev/null; then TARGET=dummy
elif modinfo loop &>/dev/null; then TARGET=loop
else echo "Aucun module lab sûr trouvé — arrêtez ici" ; exit 1
fi
echo "TARGET=$TARGET"

lsmod | grep -E "^${TARGET}\b" || true
sudo modprobe "$TARGET"
lsmod | grep -E "^${TARGET}\b"
modinfo "$TARGET" | grep -E '^(filename|description|depends):'

# Déchargement seulement si Used by = 0 et module non critique pour votre session
if [ "$TARGET" = "dummy" ]; then
  sudo rmmod dummy || sudo modprobe -r dummy
  lsmod | grep -E '^dummyb' || echo "dummy déchargé — OK"
else
  echo "loop souvent Used by > 0 : ne pas forcer rmmod ; lab lecture seule OK"
fi

Commande	Effet
sudo modprobe NOM	Charge + dépendances
sudo modprobe -r NOM	Décharge si libre
sudo rmmod NOM	Décharge brut (moins sûr que -r)

Règles lab : jamais de .ko inconnu ; jamais décharger ext4/xfs/NIC SSH ni Used by > 0. Rocky/Alma : même syntaxe ; Module not found → paquet kernel-modules.

Étape 4 — Persistance : modules-load.d et blacklist

Au boot, systemd charge les noms listés dans /etc/modules-load.d/*.conf. Pour empêcher un chargement auto : blacklist dans /etc/modprobe.d/.

# Exemple lab : charger dummy au prochain boot (à retirer après le lab)
echo 'dummy' | sudo tee /etc/modules-load.d/lab-dummy.conf
cat /etc/modules-load.d/lab-dummy.conf

# Blacklist exemple (ne l’appliquez que si vous savez pourquoi)
# echo 'blacklist pcspkr' | sudo tee /etc/modprobe.d/lab-blacklist-pcspkr.conf

# Nettoyage lab immédiat (fichier conf)
sudo rm -f /etc/modules-load.d/lab-dummy.conf
ls /etc/modules-load.d/

Fichier	Rôle
/etc/modules-load.d/*.conf	Modules à charger au boot
/etc/modprobe.d/*.conf	Options, install hooks, blacklist
/etc/modules (legacy)	Ancien fichier unique — préférer modules-load.d

Prod : versionnez (Ansible/Git) et documentez chaque blacklist (sinon boot rescue). Lab : supprimez les lab-*.conf avant de quitter.

Étape 5 — sysctl : lire /proc/sys et changer en runtime

sysctl expose des paramètres noyau sous /proc/sys/… (le . du nom remplace /). sysctl -w change la valeur jusqu’au reboot (sauf écriture persistante ensuite).

sysctl kernel.hostname
sysctl vm.swappiness
sysctl fs.inotify.max_user_watches
sysctl net.ipv4.ip_forward

# Équivalent fichier
cat /proc/sys/vm/swappiness
cat /proc/sys/net/ipv4/ip_forward

Action	Commande
Lire une clé	sysctl CLE ou cat /proc/sys/...
Lister (énorme)	sysctl -a
Écrire runtime	sudo sysctl -w CLE=VALEUR
Appliquer fichiers	sudo sysctl --system

Avant tout -w : notez la valeur d’origine dans un fichier lab.

mkdir -p ~/lab-sysctl
sysctl vm.swappiness fs.inotify.max_user_watches net.ipv4.ip_forward 
  | tee ~/lab-sysctl/orig.txt

Étape 6 — Cas DevOps : swappiness, inotify, ip_forward

Trois réglages fréquents en lab / VPS. Changez une valeur à la fois, vérifiez, restaurez.

# 1) vm.swappiness (0–100) : tendance à swaper. Lab : baisser temporairement
ORIG_SWAP=$(sysctl -n vm.swappiness)
echo "orig swappiness=$ORIG_SWAP"
sudo sysctl -w vm.swappiness=10
sysctl vm.swappiness
sudo sysctl -w "vm.swappiness=${ORIG_SWAP}"

# 2) fs.inotify.max_user_watches : IDE, CI, node_modules qui « watch »
ORIG_INOT=$(sysctl -n fs.inotify.max_user_watches)
echo "orig inotify=$ORIG_INOT"
sudo sysctl -w fs.inotify.max_user_watches=524288
sysctl fs.inotify.max_user_watches
sudo sysctl -w "fs.inotify.max_user_watches=${ORIG_INOT}"

# 3) net.ipv4.ip_forward : routage (lab routeur / note K8s nodes). Défaut souvent 0
ORIG_FWD=$(sysctl -n net.ipv4.ip_forward)
echo "orig ip_forward=$ORIG_FWD"
sudo sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward
sudo sysctl -w "net.ipv4.ip_forward=${ORIG_FWD}"

Clé	Intérêt DevOps	Prudence
vm.swappiness	DB / latence swap	Trop bas sur petite RAM = OOM plus tôt
fs.inotify.max_user_watches	Dev containers, IDE	Augmenter si « no space left on device » inotify
net.ipv4.ip_forward	NAT, lab routeur, K8s	N’activez pas sur un laptop exposé sans firewall

Persist (optionnel) : echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-lab-swappiness.conf puis sudo sysctl --system ; supprimez le fichier après le lab. Rocky/Alma : mêmes clés ; ne désactivez pas firewalld pour tester ip_forward — voir réseau & sécurité.

Étape 7 — Vérification et nettoyage lab

# Plus de conf lab
sudo rm -f /etc/modules-load.d/lab-dummy.conf
sudo rm -f /etc/sysctl.d/99-lab-swappiness.conf
sudo rm -f /etc/modprobe.d/lab-blacklist-pcspkr.conf

# Restaurer sysctl depuis le snapshot local si besoin
if [ -f ~/lab-sysctl/orig.txt ]; then
  while IFS=' = ' read -r k v; do
    [ -n "$k" ] && sudo sysctl -w "$k=$v"
  done < ~/lab-sysctl/orig.txt
fi

sysctl vm.swappiness fs.inotify.max_user_watches net.ipv4.ip_forward
lsmod | grep -E '^dummyb' || echo "dummy absent — OK"
echo "lab kernel/sysctl nettoyé"

Validé si : uname -r/lsmod OK, modprobe lab (dummy) fait puis retiré, trois sysctl lus/écrits/restaurés, aucun lab-*.conf restant.

Erreurs fréquentes

Symptôme	Cause	Correction
modprobe: FATAL: Module not found	Mauvais uname -r / paquets modules	uname -r ; installer linux-modules-$(uname -r) (Ubuntu)
rmmod: ERROR: Module is in use	Used by > 0	lsmod ; modprobe -r ; ne forcez pas
sysctl: permission denied	Sans sudo	sudo sysctl -w …
Valeur perdue au reboot	Seulement -w, pas de conf	/etc/sysctl.d/*.conf + sysctl --system
ip_forward=1 et surprise réseau	Routage ouvert	Firewall (nftables/UFW) + restaurer 0
Blacklist driver disque	/etc/modprobe.d agressif	Rescue / live USB ; retirer le conf
Confondre sysctl et systemctl	Homonymie	sysctl = noyau ; systemctl = units

Quiz (3 questions)

1. Que fait sudo modprobe dummy ?
– A. Compile le noyau avec le driver dummy
– B. Charge le module dummy (et dépendances) dans le noyau courant
– C. Active net.ipv4.ip_forward

2. Différence sysctl -w vm.swappiness=10 vs fichier dans /etc/sysctl.d/ ?
– A. -w est permanent ; le fichier est temporaire
– B. -w = runtime jusqu’au reboot ; le fichier + sysctl --system = persistance
– C. Les deux sont équivalents à systemctl restart

3. Pourquoi éviter rmmod sur un module avec Used by > 0 ?
– A. Parce que lsmod serait plus lent
– B. Des dépendants / le système l’utilisent encore — risque d’instabilité
– C. Parce que seuls les modules blacklistés se déchargent

Réponses : 1‑B · 2‑B · 3‑B

FAQ

Faut-il recompiler le noyau ?
Non — modules distro + sysctl seulement. Custom kernel hors scope.

Documenter un sysctl en équipe ?
Fichier /etc/sysctl.d/99-acme.conf versionné (Ansible) + ticket avant/après. Pas de -w orphelin.

Lien Kubernetes ?
Les nœuds touchent ip_forward et limites fichiers. Ici : lire/changer proprement sur une machine ; ne copiez pas une conf cluster sur un laptop.

Pour aller plus loin

• man modprobe, man modules-load.d, man sysctl, man sysctl.d, doc kernel /proc/sys
• Hub Linux Admin · suite prévue : performance (iostat / vmstat)

Maillage série Linux Admin

← Précédent	Hub Linux Admin · Processus avancés · systemd avancé
→ Suivant	Performance Linux : iostat, vmstat, tuning
Hub	Linux Admin
Aussi	Linux Basics · Réseau & sécurité · Vagrant

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Kernel modules & sysctl Linux : modprobe, /proc/sys (2026)
• Meta description (≤ 155) : Modules noyau (lsmod, modprobe) et sysctl persistants : ip_forward, swappiness, inotify. Guide Linux Admin DevOps 2026.
• Focus keyphrase : sysctl linux
• KW secondaires : modprobe, lsmod, kernel modules, /proc/sys
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-kernel-sysctl-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire
• Slug : linux-kernel-sysctl
• Statut : HOLD — draft only (ne pas publier)