cgroups v2 sur l'hôte : vérifier le mode et lire les limites de ressources par unité

Objectif

Déterminer dans quel mode cgroup fonctionne un hôte Linux, puis inspecter les limites de ressources que systemd (et, par son intermédiaire, les runtimes de conteneurs) applique à une unité ou à un conteneur donné.

Prérequis

Un accès shell. Les droits root ne sont pas nécessaires pour une inspection en lecture seule, mais ils le sont pour consulter certains détails de cgroups appartenant à d'autres utilisateurs.

Étapes

1. Vérifier le mode : stat -fc %T /sys/fs/cgroup. Selon la documentation du noyau sur cgroup v2, la hiérarchie unifiée est montée avec le type de système de fichiers cgroup2, que stat affiche sous la forme cgroup2fs ; cette sortie signifie que l'hôte fonctionne entièrement sous cgroup v2 (mode unifié). Si l'on obtient tmpfs, l'hôte est en configuration hybride ou historique (cgroup v1) : /sys/fs/cgroup est alors un tmpfs sous lequel sont montés des contrôleurs v1 distincts.
2. Parcourir l'arborescence sous forme de hiérarchie de slices, de scopes et de services : systemd-cgls affiche l'arbre complet des cgroups avec le ou les processus rattachés à chaque unité ; systemd-cgls /system.slice/docker.service (ou la slice concernée) restreint l'affichage à une seule branche.
3. Suivre en direct la consommation de ressources par cgroup : systemd-cgtop affiche les tâches, le CPU, la mémoire et les E/S par groupe de contrôle, avec un rafraîchissement similaire à top ; c'est utile pour repérer quel conteneur ou quel service consomme les ressources de l'hôte sans connaître son PID à l'avance.
4. Lire directement les limites configurées d'une unité systemd : systemctl show <unit> --property=MemoryMax,MemoryHigh,CPUQuotaPerSecUSec. Un conteneur Podman Quadlet s'exécute sous son unité de service ; un conteneur lancé avec docker run --memory=512m et le pilote cgroup systemd (le choix par défaut habituel sous cgroup v2) devient un docker-<id>.scope sous system.slice — avec le pilote cgroupfs, il se trouve à la place sous /sys/fs/cgroup/docker/<id>/. Dans les deux cas, lire memory.max et cpu.max dans ce répertoire donne les valeurs brutes appliquées par le noyau (max signifie sans limite).
5. Relier un conteneur à son chemin cgroup : systemctl status <container-unit> (conteneur géré par Quadlet/systemd), ou bien relever le PID principal du conteneur (docker inspect --format '{{.State.Pid}}' <container>) et lire /proc/<pid>/cgroup, dont l'unique ligne 0::<path> sous cgroup v2 donne le chemin relatif à /sys/fs/cgroup. (.HostConfig.CgroupParent est généralement vide ; il n'indique un parent que s'il a été défini explicitement.)

Résultat attendu

stat -fc %T /sys/fs/cgroup renvoie cgroup2fs ; systemd-cgtop et systemd-cgls montrent l'arborescence d'unités attendue, avec des chiffres en direct qui concordent avec ceux que le runtime de conteneurs rapporte via ses propres commandes stats.

Limites et base de vérification

Le chemin et les noms exacts des fichiers de contrôleurs (memory.max, cpu.max, etc.) sont ceux de la hiérarchie unifiée, tels que documentés dans le guide d'administration cgroup v2 du noyau ; un hôte resté sous cgroup v1 historique expose des noms de fichiers différents, propres à chaque contrôleur, ainsi que d'autres paramètres de limitation (memory.limit_in_bytes), que cet article ne couvre pas.