Ubuntu 26.04 LTS : détecter les dépendances à cgroup v1 avant l’upgrade

Un serveur Ubuntu peut fonctionner normalement depuis plusieurs années tout en conservant une dépendance à cgroup v1 : paramètre kernel historique, ancien runtime de containers, script d’exploitation ou agent de supervision qui utilise directement les anciens chemins sous /sys/fs/cgroup.

Avec Ubuntu 26.04 LTS, cette dette technique devient un véritable problème de compatibilité. Ubuntu 26.04 utilise systemd 259, et Canonical indique que la prise en charge des hiérarchies cgroup v1 legacy et hybrid a été supprimée.

L’objectif de cet article est donc de construire un preflight go/no-go : comprendre rapidement ce qu’est cgroup, déterminer la version réellement utilisée sur un serveur, rechercher les dépendances à v1 et valider les workloads avant d’envisager l’upgrade.

Rappel : à quoi sert cgroup sous Linux ?

cgroup signifie control group. C’est un mécanisme du kernel Linux qui permet d’organiser les processus dans une hiérarchie et de contrôler la manière dont certaines ressources système leur sont distribuées. Des controllers spécialisés interviennent notamment pour le CPU, la mémoire, les entrées/sorties ou le nombre de processus.

L’idée peut être représentée simplement :

Linux
│
├── groupe A
│   ├── service 1
│   └── service 2
│
└── groupe B
    └── container

Des règles peuvent ensuite limiter ou comptabiliser les ressources consommées par ces groupes.

C’est notamment ce mécanisme que systemd utilise pour organiser ses services, scopes et slices et leur appliquer des paramètres de resource control.

Les plateformes de containers s’appuient également sur les cgroups pour contrôler les ressources allouées aux containers.

cgroup v1 et cgroup v2 : la différence essentielle

Avec cgroup v1, les différents controllers pouvaient être organisés dans plusieurs hiérarchies distinctes.

On pouvait donc rencontrer des arborescences séparées pour :

/sys/fs/cgroup/cpu/
/sys/fs/cgroup/memory/
/sys/fs/cgroup/blkio/

cgroup v2 simplifie ce modèle avec une hiérarchie unique. Les controllers sont rattachés à cette même arborescence et leurs restrictions sont appliquées hiérarchiquement. C’est l’une des différences structurelles majeures entre les deux versions.

Sur un système moderne utilisant cgroup v2, on rencontre plutôt :

/sys/fs/cgroup/
├── cgroup.controllers
├── cgroup.procs
├── cpu.stat
├── memory.current
├── io.stat
└── ...

Cette différence de layout explique pourquoi un vieux script ou un outil cherchant explicitement /sys/fs/cgroup/memory/ peut devenir incompatible.

Pourquoi Ubuntu 26.04 change la situation

Ubuntu utilise cgroup v2 par défaut depuis plusieurs versions, mais cela ne signifie pas que tous les serveurs Ubuntu actuellement exploités utilisent réellement cette configuration.

Un serveur peut conserver :

une ancienne option de boot forçant cgroup v1 ;
une configuration héritée d’une migration ;
un runtime container ancien ;
des scripts internes développés pour v1 ;
un agent de monitoring qui parcourt directement les anciens controllers.

Or Ubuntu 26.04 passe de systemd 255 à systemd 259, après la suppression upstream du support des hiérarchies cgroup v1. Canonical signale explicitement ce changement dans les release notes.

Il faut donc vérifier deux choses différentes :

Le système utilise cgroup v2
              +
Les workloads fonctionnent avec cgroup v2
              =
     candidat à l'upgrade

Le premier contrôle ne garantit pas le second.

Prérequis

Commencez cet audit avant la fenêtre d’upgrade.

Vous devez connaître au minimum :

les services critiques présents sur le serveur ;
les runtimes de containers utilisés ;
les agents de monitoring et de sécurité ;
les scripts d’exploitation locaux ;
les éventuelles personnalisations de GRUB.

Les premières vérifications proposées ici sont en lecture seule.

Si une modification de la ligne de commande kernel devient nécessaire ensuite, travaillez d’abord sur une VM de test ou un clone et disposez d’un accès console.

Mise en pratique

1. Déterminer la version de cgroup réellement utilisée

Le test le plus simple consiste à rechercher :

test -f /sys/fs/cgroup/cgroup.controllers \
  && echo "cgroup v2 détecté" \
  || echo "cgroup v2 non détecté"

Docker documente également cette méthode : si cgroup.controllers existe, le système utilise cgroup v2.

Complétez avec :

findmnt -no FSTYPE /sys/fs/cgroup

Sur une hiérarchie cgroup v2 unifiée, le résultat attendu est :

cgroup2

Vous pouvez également visualiser la hiérarchie gérée par systemd :

systemd-cgls

Cette commande affiche récursivement les control groups et les processus qui leur appartiennent.

Si les contrôles indiquent déjà cgroup2, ne concluez pas encore au GO : il reste à vérifier les dépendances des workloads.

2. Vérifier si le boot force encore cgroup v1

Commencez par examiner la ligne de commande réellement transmise au kernel :

cat /proc/cmdline

Puis recherchez les paramètres cgroup dans la configuration GRUB :

grep -RniE 'cgroup|unified_cgroup' \
  /etc/default/grub /etc/default/grub.d 2>/dev/null

Un paramètre comme :

systemd.unified_cgroup_hierarchy=0

mérite une attention particulière. La documentation Docker le décrit comme le paramètre permettant de demander cgroup v1 sur les systèmes systemd ; la valeur 1 sélectionne v2. Un changement de version nécessite un redémarrage.

Ne retirez pas immédiatement ce paramètre sur un serveur de production.

S’il est présent, cherchez d’abord pourquoi il a été ajouté. Il peut avoir constitué historiquement un workaround pour une application ou un runtime.

3. Rechercher les dépendances aux anciens chemins v1

Les anciens scripts constituent une source classique de problème.

Cherchez notamment les références directes à :

/sys/fs/cgroup/memory/
/sys/fs/cgroup/cpu/
/sys/fs/cgroup/cpuacct/
/sys/fs/cgroup/blkio/

Sur des emplacements contenant vos scripts locaux :

grep -RniE '/sys/fs/cgroup/(memory|cpu|cpuacct|blkio)' \
  /usr/local /opt 2>/dev/null

Adaptez les répertoires à votre environnement.

Un résultat n’est pas automatiquement une erreur : il indique simplement qu’un composant doit être analysé.

Le layout des fichiers est sensiblement différent entre v1 et v2. Cette vérification doit aussi concerner :

scripts Ansible ou shell locaux ;
agents de monitoring ;
agents de sécurité ;
collecteurs de métriques ;
outils de capacity planning ;
applications qui contrôlent elles-mêmes leurs ressources.

4. Contrôler les containers

Si Docker est installé :

docker info

Relevez notamment :

Cgroup Driver:
Cgroup Version:

La documentation Docker indique que cgroup v2 est le mode par défaut sur Ubuntu depuis 21.10.

Sur les versions actuelles de Docker Engine, le mouvement s’accélère encore : Docker Engine 29 déprécie officiellement le support de cgroup v1. Le support doit encore être maintenu pendant une période de transition, mais Docker recommande de migrer vers v2.

Un résultat :

Cgroup Version: 2

est donc positif, mais ne suffit toujours pas.

Vérifiez ensuite que les containers critiques démarrent et exécutent réellement leurs fonctions :

docker ps

Le contrôle doit être fonctionnel, pas uniquement administratif.

5. Tester le changement sur un clone

Si le serveur fonctionne encore en v1 et qu’un paramètre de boot historique en est responsable, préparez un environnement de test représentatif.

Avant tout changement :

sauvegardez la configuration ;
conservez une entrée de boot fonctionnelle ;
assurez-vous d’avoir une console ;
vérifiez la présence des runtimes et agents importants ;
documentez le paramètre que vous retirez.

Après modification contrôlée du boot et régénération de GRUB selon la procédure Ubuntu applicable, redémarrez la machine de laboratoire.

Changer de version cgroup nécessite un reboot du système.

Résultat attendu

Commencez par le kernel :

findmnt -no FSTYPE /sys/fs/cgroup

Résultat attendu :

cgroup2

Puis :

test -f /sys/fs/cgroup/cgroup.controllers \
  && echo "OK: cgroup v2"

Ensuite, contrôlez systemd :

systemctl --failed

et les avertissements significatifs du boot :

journalctl -b -p warning

Si Docker est utilisé :

docker info
docker ps

Puis passez aux véritables critères de décision :

applications accessibles ;
agents de monitoring actifs ;
métriques CPU et mémoire remontées ;
containers critiques fonctionnels ;
automatisations opérationnelles ;
absence d’erreurs cgroup nouvelles dans les logs.

Vérification

Le résultat du preflight peut être résumé ainsi :

cgroup v2 actif
        │
        ├── paramètres de boot validés
        ├── scripts v1 traités
        ├── services validés
        ├── containers validés
        └── monitoring validé
                 │
                 ▼
          GO cgroup v2

Si l’une de ces briques échoue, le bon résultat est NO-GO.

Le but du preflight n’est précisément pas de forcer l’upgrade, mais de faire apparaître les dépendances avant la fenêtre de changement.

Bonnes pratiques

Évitez de transformer la migration en simple opération GRUB. La vraie question n’est pas seulement « cgroup v2 démarre-t-il ? », mais « mon environnement fonctionne-t-il correctement avec cgroup v2 ? ».

Pour un parc important :

commencez par une machine pilote représentative ;
conservez la liste des incompatibilités détectées ;
corrigez les scripts à la source plutôt que par workaround ;
vérifiez séparément les agents tiers ;
réexécutez le preflight juste avant l’upgrade si l’environnement a évolué.

Sécurité

Les cgroups participent à la maîtrise et à l’isolation des ressources. systemd s’appuie lui-même sur cette infrastructure pour organiser les processus de ses unités et appliquer ses mécanismes de resource control.

Évitez donc les solutions consistant à rendre arbitrairement /sys/fs/cgroup inscriptible ou à manipuler manuellement les controllers pour contourner une incompatibilité.

La modification du boot constitue également un risque opérationnel : une mauvaise configuration peut rendre la machine inaccessible à distance. Un test sur clone et un accès console sont donc préférables avant toute intervention sur un serveur critique.

Coûts

Aucune licence supplémentaire n’est nécessaire pour réaliser ce preflight.

Un lab sur une VM locale ou un clone d’une infrastructure existante peut être réalisé sans coût logiciel supplémentaire.

Avec une VM cloud, les coûts éventuels concernent principalement la VM, son stockage et les snapshots. Les ressources temporaires doivent être supprimées après le test.

Limites et points de vigilance

Ce contrôle n’est pas un audit complet de compatibilité Ubuntu 26.04.

L’upgrade devra également prendre en compte :

packages tiers ;
repositories supplémentaires ;
drivers ;
changements systemd autres que cgroup ;
applications spécifiques au serveur.

De plus, un logiciel peut être incompatible avec v2 sans contenir explicitement un ancien chemin détectable par grep.

En cas d’échec sur l’environnement de test, revenez à la configuration de boot précédente et identifiez le composant incompatible avant de poursuivre.

Ne lancez pas la migration Ubuntu 26.04 sur un serveur encore dépendant de cgroup v1 : Ubuntu 26.04 a précisément supprimé ce mode de fonctionnement.

Rollback ou nettoyage

Si le changement n’a été effectué que sur un clone, le rollback le plus sûr consiste simplement à revenir à l’environnement source.

Sur une machine de test modifiée, restaurez la configuration de boot précédente si un composant critique ne fonctionne plus.

Avant toute modification, conservez une copie de la configuration concernée et assurez-vous de pouvoir sélectionner une entrée de boot fonctionnelle depuis la console.

Références officielles

Ubuntu 26.04 LTS — Summary for LTS users — Canonical
Ubuntu 26.04 LTS — Changes since 25.10 — Canonical
Control Group v2 — Linux Kernel documentation
Control Group APIs and Delegation — systemd
Runtime metrics — Control groups — Docker Documentation
Deprecated Docker Engine features — Docker Documentation

Conclusion

Ubuntu 26.04 ne fait pas que rendre cgroup v2 préférable : la disparition de la compatibilité cgroup v1 dans systemd transforme les anciennes dépendances en véritable critère de préparation.

La méthode est donc simple : identifier, inventorier, tester et valider.

Un serveur n’est prêt que lorsque cgroup v2 fonctionne au niveau système et que ses services, containers, scripts et outils de supervision ont été vérifiés.