C’est une bonne idée ! ça enlève tout « hack » système.
Je pense que ça peut marcher, le seul cas où ça marcherait pas c’est le cas où quelqu’un lance 2 instances Gladys en parallèle (parce que bon je pense pas que d’autre projets auraient une image Docker avec le nom « gladys »)
Bon je suis revenu à la méthode hacky avec un grep / sed qui gère les deux cas ( testé en cgroup v1 et v2 )
Aha il y a rien de mieux que cette méthode pour ça au final 
Ca fonctionne avec les deux versions du coup, autant sur Debian 10 que 11 ?
Si oui c’est top !
Oui dans les deux cas, les instances actuelles ne sont donc pas impactées.
Restera à mettre à jour la doc et l’image de test Buster
Juste une question, pourquoi avant on avait pas besoin d’ajouter de paramètres spécifiques dans le docker run, et maintenant il faudrait ?
Pour la faire courte en cgroupsv1 l’argument --privileged était suffisant.
En cgroups v2 docker n’expose qu’avec l’argument --cgroupns host 
Faut que j’essaye de lister un max les versions d’OS concernées pour la doc.
Merci pour l’explication! Effectivement du coup, il faut rajouter ça.
Et si l’option est présente sur les anciennes version, ça ne pose pas de problème ?
docker run --cgroupns host ne change rien sur un Debian 10 ?
Non ça change rien
Seul pre requis Docker 20.10.0 mini ( sorti en 08/2020 ) car cette argument est arrivé avec l’api en V1.41
Je viens de découvrir l’option --cidfile
On aurait juste à lire un fichier a priori
Incroyable ça ! en fait on s’est embêté pour rien ? 
ça a l’air dispo depuis longtemps en plus, j’ai vu des posts de 2015 qui en parlent.
Il faudra quand même garder le fonctionnement actuel pour toutes les installations qui tournent en production sans
ouai je viens de tester c’est exactement ce qu’on veut ,le full id.
On test l’existence du fichier et s’il n’existe pas, ancienne méthode.
Comme ça on rajoute pas d’argument permissif pour les nouveaux déploiments et le legacy fonctionne toujours.
ça me parait parfait ça ! belle trouvaille 
…et vous envisagez une version 64 bit ?
Pour info :
Titre assez clickbait ! ^^
Le test a été effectué sur un Raspberry Pi 400 avec 4Go de RAM, donc oui dans ce cas là ça fait un vrai boost car un système 32 bits gère environ 3.5 GB de RAM max, et le passage au 64 bits permet à un seul process de prendre toute la RAM au besoin
Sur n’importe quel autre Pi, le gain ne sera pas aussi fort, et il peut même être négatif sur certain modèle.
Mais je suis d’accord sur le fait qu’avoir une image 64 bits sera utile, à partir du Pi 4 d’après les benchmark il y a un vrai intérêt
( Et j’ai cru voir des leaks d’un Raspberry Pi 4 + qui aurait jusqu’à 16Go de RAM… Là ce sera clairement nécessaire )
Leur spécialité !
Le prix va piquer !
Tu as raison, si ça ajoute même 2% de perf en plus c’est l’idéal de passer en 64 bit.
Là où ça m’intéresse, c’est que théoriquement un système 64 bits peut avoir des performances améliorées sur les opérations genre chiffrement/compression.
Dans Gladys, ça peut avoir un vrai impact sur toute la partie Gladys Plus :
Oui y’a juste a faire un fichier de conf dédié, je préfère qu’on fixe d’abord bullseye, si tout roule on fera du 64 bits.
Si besoin de test, j’ai un RPi 4 4Go et SSD Gladys est dessus mais c’est aussi mon Media Center (Kodi) d’où mon intérêt pour des performances améliorées 