OK le soucis usb je t’avoue que j’ai pas eu le temps de check
Ce qui est censé être corrigé c’est la détection de docker, pour l’intégration mqtt par exemple
Bon j’ai continuer le debug
cgroupv1 et v2 c’est pas la même histoire
J’ai réussi à rendre fonctionnelle la partie docker en trichant
if (!this.networkMode) {
const cmdResult = await exec('head -1 /proc/self/cgroup | cut -d/ -f3');
if (cmdResult.indexOf('docker') > -1) {
result = cmdResult.split(/[-/.]+/);
var cmdResult2 = result[1];
} else {
var cmdResult2 = cmdResult;
}
const [containerId] = cmdResult2.split('\n');
C’est moche mais ça marche ( on rigole pas j’ai fait ça avec nano dans le conteneur ^^ )
La chaine retournée est différente
0::/system.slice/docker-5c11f71a9288d80aafed5d79fa0b02987a1eb90f430538c50cbe93cc190a11d8.scope
avant c’était plutôt ( juste l’id )
12:perf_event:/docker/1e8406126867fe82f2490c6bb4ea7b4905a972250f7f652d650da0713caa6392
Résultat:
Je me penche sur la partie USB maintenant
@pierre-gilles y’a surement plus élégant pour tester et split les deux type de chaine, j’ai fait ça juste pour tester
@VonOx ce que tu as changé ça fonctionnera dans Debian 10 toujours ?
C’est dingue quand même qu’il y ait pas une méthode accessible simple ^^
Yep ça check les deux, c’est pas vraiment spécifique à l’os mais à la version de cgroup.
1 « J'aime »
Bon j’ai réfléchi un peu à la logique pour essayer d’utiliser uniquement dockerode
La méthode deviendrai
if (!this.networkMode) {
const searchContainer = await this.dockerode.listContainers({
filters: { image: ['*/gladys:*'] },
});
const gladysContainer = this.dockerode.getContainer(searchContainer.id);
const gladysContainerInspect = await gladysContainer.inspect();
this.networkMode = get(gladysContainerInspect, 'HostConfig.NetworkMode', { default: 'unknown' });
}
L’idée c’est de chopper l’id par son image ( pas du tout testé c’est juste une reflexion)
@AlexTrovato @pierre-gilles vous en pensez quoi ?
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 )
1 « J'aime »
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.
1 « J'aime »
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
1 « J'aime »
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.
2 « J'aime »
ça me parait parfait ça ! belle trouvaille 
…et vous envisagez une version 64 bit ?
Pour info :