OK, the USB issue, I admit I didn’t have time to check
What is supposed to be fixed is the detection of Docker, for MQTT integration, for example
I continued debugging
cgroupv1 and v2 are not the same story
I managed to make the docker part work by cheating
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');
It’s ugly but it works (no laughing, I did this with nano in the container ^^)
The returned string is different
0::/system.slice/docker-5c11f71a9288d80aafed5d79fa0b02987a1eb90f430538c50cbe93cc190a11d8.scope
Before it was more like (just the id)
12:perf_event:/docker/1e8406126867fe82f2490c6bb4ea7b4905a972250f7f652d650da0713caa6392
Result:
Now I’m working on the USB part
@pierre-gilles there’s probably a more elegant way to test and split the two types of strings, I just did this to test
@VonOx will this still work in Debian 10?
It’s crazy that there isn’t a simple accessible method anyway ^^
Yep that checks both, it’s not really specific to the OS but to the version of cgroup.
I’ve been thinking a bit about the logic to try to use only dockerode
The method will become
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' });
}
The idea is to get the id by its image (not tested at all, it’s just a thought)
@AlexTrovato @pierre-gilles what do you think?
That’s a good idea! It removes all system « hacks ».
I think it can work, the only case where it wouldn’t work is the case where someone launches 2 Gladys instances in parallel (because well I don’t think other projects would have a Docker image with the name « gladys »)
Well, I went back to the hacky method with a grep/sed that handles both cases (tested in cgroup v1 and v2)
There’s nothing better than this method in the end 
Does it work with both versions, on both Debian 10 and 11?
If so, that’s great!
Yes in both cases, the current instances are therefore not affected.
The documentation and Buster test image will need to be updated.
Just a question, why before did we not need to add specific parameters in the docker run, and now we would?
In short, in cgroupsv1 the --privileged argument was sufficient.
In cgroups v2, Docker only exposes it with the --cgroupns host argument 
I need to try to list as many affected OS versions as possible for the documentation.
Thanks for the explanation! Indeed, in that case, we need to add that.
And if the option is present in older versions, is there any issue?
Does docker run --cgroupns host do nothing on Debian 10?
No change
Only prerequisite Docker 20.10.0 minimum (released in 08/2020) as this argument arrived with the API in V1.41
I just discovered the --cidfile option
We would just have to read a file a priori
Incredible! So we’ve been making things difficult for nothing? 
It seems to have been available for a long time, I saw posts from 2015 talking about it.
We will still need to keep the current functionality for all production installations without
That sounds perfect to me! Great find 
…and are you planning a 64-bit version?
Good question, @VonOx any idea how to do 64-bit builds from the repo?
For information: