A more reliable way to get the container id.

[adarnimrod]

The hostname is not always the container id. Get the container id from
/proc/1/cgroup. Fixes #1918.

[asottile]

what happens if the container is configured with cgroup options? does that affect this value

also tests need to be fixed

[adarnimrod]

If I understand your question correctly, it doesn't matter if the container is created with or without setting any resource limits, the control group is created anyway. From my experience, this is the most reliable way to get the container id from inside the container itself. I'll see what needs to be fixed in the tests. Thanks for the quick reply.

[asottile]

I meant more https://docs.docker.com/engine/reference/run/#specify-custom-cgroups -- does this not affect the contents of /proc/1/cgroup ?

[adarnimrod]

I did the following test:

$ docker run --rm --cgroup-parent foo alpine:3.13 cat /proc/1/cgroup
12:freezer:/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
11:perf_event:/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
10:blkio:/system.slice/containerd.service/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
9:hugetlb:/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
8:pids:/system.slice/containerd.service/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
7:cpu,cpuacct:/system.slice/containerd.service/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
6:cpuset:/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
5:memory:/system.slice/containerd.service/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
4:rdma:/
3:devices:/system.slice/containerd.service/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
2:net_cls,net_prio:/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
1:name=systemd:/system.slice/containerd.service/foo/1c7532a506b51e4072102771d0b0cc30e2300f3f539cdd6e3d8b3046275bb79f
0::/system.slice/containerd.service

So it seems that the container ID is still there as expected. I'll go over the failing tests in the weekend.

[adarnimrod]

@asottile I think I addressed everything and tests are now passing.

[asottile]

according to this SO post the method you're using is not consistent on all kernel versions: https://stackoverflow.com/q/20995351/812183

[adarnimrod]

You're going to make this on me, are you? 😜
I'm guessing you're referring to this specific answer https://stackoverflow.com/a/52081984 .
The above test I ran locally using Docker 20.10 and kernel version 5.4.
Here's the content of /proc/1/cgroup in Ubuntu Trusty (Docker 1.6 and kernel version 3.13):

11:hugetlb:/
10:perf_event:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
9:blkio:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
8:freezer:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
7:devices:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
6:memory:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
5:cpuacct:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
4:cpu:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
3:cpuset:/docker/3eae25f6afca4ec0df8b9288c3658fde47a31dfe88c0a02474cda89d166e307d
2:name=systemd:/

And here's the content in Ubuntu Xenial (Docker 18.09 and kernel version 4.4):

11:perf_event:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
10:cpuset:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
9:freezer:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
8:net_cls,net_prio:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
7:hugetlb:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
6:memory:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
5:devices:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
4:pids:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
3:blkio:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
2:cpu,cpuacct:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b
1:name=systemd:/docker/7f2ee26c7145e4a6ac67fbba7284199ff92e4a4a3aea1eefde5edda7e2bee13b

From these tests I see that the first line doesn't always have the container id, however the line that starts with 6:memory: does. Is using the container id from that specific line an OK solution?

[adarnimrod]

@asottile I think it's ready now.

[asottile]