OK, das USB-Problem gebe ich zu, da hatte ich keine Zeit, das zu prüfen
Was behoben sein sollte, ist die Erkennung von Docker, zum Beispiel für die MQTT-Integration
Okay, ich habe weiter debuggt
cgroupv1 und v2 sind zwei verschiedene Paar Schuhe
Ich habe es geschafft, den Docker-Teil zum Laufen zu bringen, indem ich geschummelt habe
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');
Es ist hässlich, aber es funktioniert (man lacht nicht, ich habe das mit nano im Container gemacht ^^ )
Die zurückgegebene Zeichenkette ist anders
0::/system.slice/docker-5c11f71a9288d80aafed5d79fa0b02987a1eb90f430538c50cbe93cc190a11d8.scope
Früher war es eher (nur die ID)
12:perf_event:/docker/1e8406126867fe82f2490c6bb4ea7b4905a972250f7f652d650da0713caa6392
Ergebnis:
Jetzt kümmere ich mich um den USB-Teil
@pierre-gilles es gibt sicherlich eine elegantere Möglichkeit, um zu testen und die beiden Arten von Zeichenketten zu trennen, ich habe das nur zum Testen gemacht
@VonOx funktioniert das, was du geändert hast, immer noch in Debian 10?
Es ist schon verrückt, dass es keine einfache, zugängliche Methode gibt ^^
Ja, das passt beides, es ist nicht wirklich spezifisch für das Betriebssystem, sondern für die Version von cgroup.
Also, ich habe ein bisschen über die Logik nachgedacht, um nur dockerode zu verwenden
Die Methode würde werden
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' });
}
Die Idee ist, die ID über das Bild zu ergattern (noch nicht getestet, das ist nur eine Überlegung)
@AlexTrovato @pierre-gilles was denkt ihr?
Das ist eine gute Idee! Damit entfallen alle „System-Hacks“.
Ich denke, das könnte funktionieren. Der einzige Fall, in dem es nicht funktionieren würde, wäre, wenn jemand zwei Gladys-Instanzen parallel startet (weil ich nicht denke, dass andere Projekte ein Docker-Image mit dem Namen „gladys“ hätten).
Na gut, ich bin zur Hack-Methode mit einem grep / sed zurückgekehrt, die beide Fälle abdeckt (getestet in cgroup v1 und v2)
Aha, es gibt nichts Besseres als diese Methode dafür am Ende 
Funktioniert das mit beiden Versionen, also sowohl mit Debian 10 als auch 11?
Wenn ja, ist das super!
Ja, in beiden Fällen sind die aktuellen Instanzen nicht betroffen.
Es bleibt noch, die Dokumentation und das Test-Image Buster zu aktualisieren.
Nur eine Frage, warum brauchte man früher keine spezifischen Parameter beim docker run hinzuzufügen, und jetzt müsste man das?
Kurz gesagt, in cgroupsv1 reichte der Argument --privileged. In cgroups v2 stellt Docker nur mit dem Argument --cgroupns host 
bereit.
Ich muss versuchen, so viele wie möglich der betroffenen OS-Versionen für die Dokumentation aufzulisten.
Danke für die Erklärung! Tatsächlich muss man das dann hinzufügen.
Und wenn die Option in älteren Versionen vorhanden ist, gibt es dann ein Problem?
docker run --cgroupns host ändert nichts an einem Debian 10?
Nein, das ändert nichts
Einzige Voraussetzung ist Docker 20.10.0 mini (veröffentlicht 08/2020), da dieser Parameter mit der API in Version 1.41 eingeführt wurde
Ich habe gerade die Option --cidfile entdeckt
Man müsste einfach eine Datei lesen.
Unglaublich! Haben wir uns etwa völlig umsonst geärgert? 
Das scheint schon seit Ewigkeiten verfügbar zu sein, ich habe Beiträge aus dem Jahr 2015 darüber gesehen.
Den aktuellen Funktionsumfang müssen wir trotzdem für alle Produktivsysteme beibehalten.
Das klingt perfekt! Tolle Idee 
…und planen Sie eine 64-Bit-Version?
Gute Frage, @VonOx hast du eine Idee, wie man 64-Bit-Builds aus dem Repo erstellen kann?
Zur Info: