Processus avancés Linux : niceness, cgroups et limites

À la fin de ce tutoriel, vous saurez lire et ajuster la niceness (nice / renice), inspecter les priorités avec ps -o ni, fixer des plafonds soft/hard via ulimit, borner CPU/RAM d’un process lab avec cgroups linux (systemd-run -p MemoryMax= / CPUQuota=), et lire /proc/<pid>/ (status, limits, cgroup) — sur machine 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-processus-avances · Série : Linux Admin · Remplace / fusionne : N/A — création (chapitre 1)

Prérequis

• Hub Linux Admin et Basics processus & systemd (ps, kill, systemctl)
• VM ou WSL jetable (Ubuntu/Debian ou Rocky/Alma 9) avec systemd et cgroups v2 (défaut Ubuntu 22.04+, Debian 12, Rocky/Alma 9)
• Compte non-root avec sudo pour systemd-run / certains renice ; pas de secrets ; lab dans /tmp et process jetables

Coût estimé : 0 €. Units transitoires via systemd-run (disparaissent au stop).

Ce que nous allons construire

Rappels PID / priorités (suite Basics)
  → nice / renice + lecture ps -o ni,pri
  → ulimit soft/hard (nofile, nproc) — lab sous-shell
  → cgroups v2 : /sys/fs/cgroup + systemd-run MemoryMax / CPUQuota
  → Inspection /proc/<pid>/{status,limits,cgroup}
  → Vérification + nettoyage lab

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Processus Linux avancés : nice, renice, ulimit, cgroups v2 via systemd-run, /proc ».)

Premier chapitre de Linux Admin. Après processus & systemd, on passe de « voir / tuer / superviser » à prioriser et borner. Analogie cloud : nice ≈ priorité relative ; cgroups linux ≈ resources.limits d’un conteneur — ici sans Docker.

Étape 1 — Rappels PID et priorités (suite Basics)

Un PID identifie une instance. La niceness (échelle -20…+19, défaut 0) influence qui obtient le CPU en contention : plus le nombre est élevé, plus le process est « gentil ».

Concept	Où le voir	Rôle
PID / PPID	ps -o pid,ppid,cmd	Identité et parent
Niceness (NI)	ps -o ni	Priorité relative
Priorité (PRI)	ps -o pri	Valeur dérivée scheduler
État	ps -o stat	R/S/D/Z… (rappel Basics)

ps -o pid,ppid,user,ni,pri,stat,cmd -p $$
ps -eo pid,user,ni,pri,pcpu,cmd --sort=ni | head -n 15

nice ne tue pas : il change la place dans la file CPU. Deux process à NI=0 se partagent à peu près équitablement ; un batch à NI=15 cède volontiers face à un shell interactif. Pour un plafond RAM/CPU dur (isolation, pas seulement « politesse »), passez aux cgroups (étape 4).

Étape 2 — nice / renice et lecture ps -o ni

nice lance avec une niceness ; renice modifie un PID existant. Sans root, on peut en général augmenter NI ; baisser vers le négatif demande souvent sudo.

nice -n 10 sleep 300 &
SPID=$!
echo "PID lab = $SPID"
ps -p "$SPID" -o pid,user,ni,pri,stat,cmd
renice -n 15 -p "$SPID"
ps -p "$SPID" -o pid,ni,cmd
renice -n 5 -p "$SPID" 2>&1 || echo "attendu : permission refusée sans sudo"
# sudo renice -n -5 -p "$SPID"   # optionnel lab VM
kill "$SPID" 2>/dev/null || true

Commande	Effet	Prudence
nice -n 10 cmd	Démarre avec NI=10	Plage -20…19
renice -n 15 -p PID	Change NI	Vos PID lab seulement
sudo renice -n -10 -p PID	Plus agressif	Jamais sshd/systemd

Rocky/Alma 9 : mêmes nice / renice / ps -o ni. Ne renice pas les process d’autres users. Astuce lab : gardez un onglet watch -n1 'ps -p PID -o pid,ni,pcpu,cmd' pendant que vous jouez avec renice pour voir NI et %CPU évoluer sous charge réelle (une boucle yes >/dev/null courte, puis Ctrl+C).

Étape 3 — ulimit soft/hard : open files et nproc

ulimit pose les plafonds du shell et de ses enfants :

• Soft : limite active courante
• Hard : plafond non dépassable sans privilèges

Cas DevOps fréquents : nofile (fichiers / sockets) et nproc (nombre de process). Symptôme classique : Too many open files.

ulimit -a | head -n 15
echo "nofile soft=$(ulimit -Sn) hard=$(ulimit -Hn)"
echo "nproc  soft=$(ulimit -Su) hard=$(ulimit -Hu)"

# Lab sûr : sous-shell — n’altère pas la session parente
bash -c '
  ulimit -Sn 64
  echo "lab soft nofile=$(ulimit -Sn)"
  python3 - << "PY" || true
import os
fds = []
try:
    for i in range(200):
        fds.append(open("/dev/null"))
except OSError as e:
    print("OSError attendue (nofile) :", e)
finally:
    for f in fds:
        f.close()
print("fds max lab :", len(fds))
PY
'
echo "parent intact : soft nofile=$(ulimit -Sn)"

Limite	Flag	Symptôme
Fichiers ouverts	-n (-Sn/-Hn)	Too many open files
Process user	-u	fork : Resource temporarily unavailable
Taille fichier	-f	écriture refusée / tronquée

Ne baissez pas durablement ulimit -Hn sur votre compte admin. Plafonds système (limits.conf, LimitNOFILE=) : hors cœur — on reste shell + /proc.

Étape 4 — cgroups linux v2 : borner avec systemd-run

Les cgroups linux comptent et limitent CPU, mémoire, I/O. Sur Ubuntu 22.04+/Debian 12/Rocky 9 : cgroup v2 sous /sys/fs/cgroup.

mount | grep -E 'cgroup2|cgroup ' | head
ls /sys/fs/cgroup | head -n 15
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null || true

Éviter d’éditer à la main memory.max / cpu.max. systemd-run crée une scope transitoire avec -p — lab jetable, pas un modèle prod.

systemd-run --user --scope -p MemoryMax=50M -p CPUQuota=20% 
  --unit=lab-cgroup-scope 
  sleep 120 &
sleep 0.5
pgrep -a -f 'sleep 120' | head
LPID=$(pgrep -n -f 'sleep 120' || true)
echo "PID lab cgroup = ${LPID:-inconnu}"
if [ -n "${LPID:-}" ]; then
  cat /proc/"$LPID"/cgroup
  grep -E 'Max open files|Max processes' /proc/"$LPID"/limits || true
fi
# Si --user échoue : sudo systemd-run --scope -p MemoryMax=50M -p CPUQuota=20% sleep 120

Propriété	Effet lab	Analogie
MemoryMax=50M	OOM si dépassement	limit mémoire conteneur
CPUQuota=20%	Plafond CPU relatif	cpu quota CFS
TasksMax=	Cap tâches/pids	pids limit

Rocky/Alma : même systemd-run ; si Failed to connect to bus, variante sudo ou loginctl enable-linger en lab. Ne bornez jamais sshd / systemd. Pour vérifier qu’une propriété est bien appliquée : systemctl --user show lab-cgroup-scope.scope -p MemoryMax -p CPUQuota (ou sans --user en variante system). Si la scope a déjà disparu, relancez le systemd-run puis show immédiatement.

Étape 5 — /proc/<pid>/ : status, limits, cgroup

Fichier	Contenu utile
/proc/<pid>/status	Name, State, VmRSS, Threads
/proc/<pid>/limits	Soft/Hard (nofile, nproc…)
/proc/<pid>/cgroup	Chemin cgroup v2

sleep 90 &
PP=$!
grep -E '^(Name|State|Pid|PPid|VmRSS|Threads):' /proc/"$PP"/status
head -n 12 /proc/"$PP"/limits
cat /proc/"$PP"/cgroup
awk '{print "nice_field=", $19}' /proc/"$PP"/stat
kill "$PP" 2>/dev/null || true

Lectures sans effet de bord : idéal avant de toucher une unit. Suite naturelle : corréler avec journalctl au prochain chapitre.

Étape 6 — Vérification et nettoyage lab

systemctl --user stop lab-cgroup-scope.scope 2>/dev/null || true
pkill -f 'sleep 120' 2>/dev/null || true
pkill -f 'sleep 300' 2>/dev/null || true
pkill -f 'sleep 90' 2>/dev/null || true
pgrep -af 'sleep (90|120|300)' || echo "aucun sleep lab — OK"
systemctl --user reset-failed 2>/dev/null || true
echo "nofile soft parent=$(ulimit -Sn)"

Validé si : ps -o ni reflète nice/renice, le sous-shell ulimit -Sn 64 provoque une OSError contrôlée, systemd-run laisse un chemin dans /proc/<pid>/cgroup, et le nettoyage ne laisse aucun sleep lab résiduel. Conservez ces trois réflexes pour la suite Linux Admin : priorité, plafond shell, plafond cgroup.

Erreurs fréquentes

Symptôme	Cause	Correction
renice: Permission denied	Baisser NI sans root / PID étranger	Augmentez NI sans sudo ; sudo seulement sur vos PID lab
Too many open files	Soft nofile trop bas	Lire /proc/PID/limits ; unit LimitNOFILE= hors lab shell
Failed to connect to bus	Session user systemd absente	sudo systemd-run ou linger lab
MemoryMax sans effet	v1 / -p mal placé	Vérifier cgroup.controllers ; -p sur --scope
CPUQuota « invisible »	sleep idle	Normal ; boucle CPU lab pour mesurer
Éditer memory.max à la main	Droits / hors systemd	Préférer systemd-run -p
Confondre nice et cgroups	Priorité vs plafond	Combiner selon latence vs isolation

Quiz (3 questions)

1. Que fait nice -n 10 commande ?
– A. Tue la commande après 10 s
– B. Lance avec niceness +10 (moins prioritaire CPU)
– C. Fixe MemoryMax=10M

2. Différence soft / hard ulimit ?
– A. Soft = plafond root ; hard = affichage seul
– B. Soft = limite active ; hard = plafond sans privilèges
– C. Soft = CPU ; hard = RAM seulement

3. Pourquoi systemd-run -p MemoryMax= pour un lab cgroups linux ?
– A. Compiler le noyau plus vite
– B. Créer une scope transitoire bornée sans unit permanente
– C. Remplacer ps aux

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

FAQ

Différence nice et cgroups linux ?
nice / renice : priorité relative CPU (qui passe devant en contention). Cgroups : plafonds mesurables (RAM, quota CPU, pids). Un process nice +19 peut encore saturer la RAM sans cgroup borné — d’où le combo admin : nice pour les jobs batch, cgroups pour isoler un lab ou un service bruyant.

Où lire les limites d’un process lancé ?
/proc/<pid>/limits, /proc/<pid>/status, niceness via ps -o ni -p PID, cgroup dans /proc/<pid>/cgroup.

systemd-run en production ?
Parfait pour lab et tests. En prod : unit .service versionnée avec MemoryMax= / CPUQuota=, plus enable. Les logs (journalctl) aident à corréler OOM.

Pour aller plus loin

• man nice, man renice, man systemd-run, man systemd.resource-control, doc cgroup v2
• Hub Linux Admin · suite : journaux et rotation

Maillage série Linux Admin

← Précédent	Hub Linux Admin · Bases : processus & systemd
→ Suivant	Logs Linux : journalctl, rsyslog et rotation
Hub	Linux Admin
Aussi	Linux Basics · limites conteneurs (Docker / K8s)

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Processus Linux avancés : nice, cgroups, ulimit (2026)
• Meta description (≤ 155) : Bornez CPU/RAM avec cgroups et systemd-run ; nice/renice et ulimit. Guide Linux Admin DevOps 2026.
• Focus keyphrase : cgroups linux
• KW secondaires : nice renice, ulimit, /proc
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-processus-avances-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire
• Slug : linux-processus-avances
• Statut : HOLD — draft only (ne pas publier)