cgroups v2 auf dem Host: Modus prüfen und Ressourcenlimits pro Unit auslesen

Ziel

Feststellen, in welchem cgroup-Modus ein Linux-Host läuft, und die Ressourcenlimits prüfen, die systemd (und darüber Container-Runtimes) für eine bestimmte Unit oder einen bestimmten Container setzt.

Voraussetzungen

Shell-Zugriff; für die rein lesende Inspektion sind keine Root-Rechte nötig, wohl aber, um einzelne cgroup-Details anderer Benutzer einzusehen.

Schritte

1. Modus prüfen: stat -fc %T /sys/fs/cgroup. Laut der Kernel-Dokumentation zu cgroup v2 wird die vereinheitlichte Hierarchie als Dateisystemtyp cgroup2 eingehängt, den stat als cgroup2fs ausgibt; diese Ausgabe bedeutet, dass der Host vollständig auf cgroup v2 (Unified-Modus) läuft. Erscheint stattdessen tmpfs, liegt ein hybrides oder veraltetes Setup (cgroup v1) vor, bei dem /sys/fs/cgroup ein tmpfs ist und darunter separate v1-Controller-Mounts liegen.
2. Den Baum als Hierarchie aus Slices, Scopes und Services durchsuchen: systemd-cgls gibt den gesamten cgroup-Baum samt den Prozessen unter jeder Unit aus; systemd-cgls /system.slice/docker.service (oder der jeweilige Slice) beschränkt die Ausgabe auf einen Zweig.
3. Die aktuelle Ressourcennutzung pro cgroup beobachten: systemd-cgtop zeigt Tasks, CPU, Speicher und I/O pro Control Group und aktualisiert sich wie top. Das hilft, den Container oder Service mit hohem Ressourcenverbrauch zu finden, ohne vorher dessen PID zu kennen.
4. Die konfigurierten Limits einer systemd-Unit direkt auslesen: systemctl show <unit> --property=MemoryMax,MemoryHigh,CPUQuotaPerSecUSec. Ein Podman-Quadlet-Container läuft unter seiner Service-Unit; ein Container, der mit docker run --memory=512m und dem systemd-cgroup-Treiber (unter cgroup v2 üblicherweise der Standard) gestartet wird, erscheint als docker-<id>.scope unter system.slice – mit dem Treiber cgroupfs liegt er stattdessen unter /sys/fs/cgroup/docker/<id>/. In beiden Fällen liefern memory.max und cpu.max in diesem Verzeichnis die rohen, vom Kernel durchgesetzten Werte (max bedeutet unbegrenzt).
5. Einen Container seinem cgroup-Pfad zuordnen: systemctl status <container-unit> (bei Quadlet/systemd-verwalteten Containern) oder die Haupt-PID des Containers ermitteln (docker inspect --format '{{.State.Pid}}' <container>) und /proc/<pid>/cgroup lesen; die einzelne Zeile 0::<path> enthält unter cgroup v2 den Pfad relativ zu /sys/fs/cgroup. (.HostConfig.CgroupParent ist meist leer; es zeigt nur einen ausdrücklich gesetzten Parent.)

Erwartetes Ergebnis

stat -fc %T /sys/fs/cgroup meldet cgroup2fs; systemd-cgtop und systemd-cgls zeigen den erwarteten Unit-Baum mit Live-Werten, die mit den Angaben übereinstimmen, die die Container-Runtime über ihre eigenen stats-Befehle liefert.

Grenzen und Prüfbasis

Pfad und genaue Namen der Controller-Dateien (memory.max, cpu.max usw.) entsprechen den Namen der vereinheitlichten Hierarchie aus dem cgroup-v2-Administrationshandbuch des Kernels. Ein Host mit veraltetem cgroup v1 stellt andere, pro Controller getrennte Dateinamen und andere Limit-Parameter bereit (memory.limit_in_bytes); dieser Artikel behandelt sie nicht.