Mounting cgroups in a container #66
Labels
Comments
|
The main feature that we are asking for is introspection so that the container process can see its own cgroups. The could be mounted RO, so the container can't modify its own cgroups. The main contention here is where should these be mounted and if we can come up with a standard location then there could be some tooling that could benefit from it. |
|
Are there applications today that expect to have a sub-tree cgroup mount? If not I would suggest that we make the container cgroup path easily discoverable via an environment variable. The basic process would be to mount the entire heirarchy as RO and then via an environment variable like, If in the future we are able to fix-up the Kernel we could then make Thoughts? |
|
I think the canonical way to know the container cgroup path should be to parse On the host, this returns Applications should expect to find If in the future the kernel implements cgroup namespacing, then |
|
The downside of mounting the entire cgroups hierarchy is that the container can read the limits of all the other containers. I agree that it will be great if we see / when the kernel namespacing is implemented. However, what we are proposing is an approximation of that as the container can only see its own cgroups and not of other containers/processes on the host. |
|
I understand the downside and fully sympathize with the "annoyingness" of being able to read the limits of other cgroups. But, I would rather wait for the Kernel to correctly virtualize/namespace this and then enable the Kernel namespacing instead of working around the lack of namespaces and making things internally inconsistent. |
👍 |
|
@philips I agree. |
|
/cc @vmarmol |
|
Mounting cgroups would impact checkpoint - restore functionality. FYI. |
|
So, I am going to put up a PR that will spec out mounting the system cgroup as a read-only bind-mount and the 'sub-cgroup' of the container optionally as a read-write bind-mount. This should be backwards compatible once the cgroup namespace is merged and requires no "magic". @vmarmol Can you ping Aditya about: https://lkml.org/lkml/2014/10/19/4 |
|
I pinged Aditya and he mentioned he has mostly not had time to continue the patch set and he wasn't getting any pressure to get it in. The only negative feedback he received on the patch set was that it only worked on unified hierarchy. He says he can make it work with the split hierarchy, but that it'd be more work overall. |
|
Here we have sorta implementation detail. For example in |
|
@vmarmol If we can push for just unified that would work for me. |
|
That was a primary complaint from reviewers, maybe the can be convinced
|
|
cgroups namespaces patch has been revived http://lists.linuxfoundation.org/pipermail/containers/2015-November/036378.html :) |
|
I chatted briefly with Aditya about this patch. This should get merged On Mon, Nov 16, 2015 at 4:29 PM, Mrunal Patel notifications@github.com
|
|
SUPER! On Mon, Nov 16, 2015 at 11:04 PM, Vish Kannan notifications@github.com
|
|
OK, the patch is super exciting. Thanks for the update @mrunalp and @vishh. This makes it easy to argue for mounting cgroup hierarchy read-only with the sub-cgroup as read-write (#66 (comment)). So, lets push forward on that. |
|
Hmm, why is this part of the spec? Isn't this just a mount config as @LK4D4 says? |
|
cgroup namespace support was added by: #397 I think we can close this. |
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 22, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Nov 23, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Dec 7, 2017
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. - Also added couple of APIs to return container type and name. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Feb 19, 2018
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
ashu-mehra
pushed a commit
to ashu-mehra/omr
that referenced
this issue
Feb 20, 2018
Add support in port library for detecting if we are running in docker container or not. This is required for cgroup related APIs in port library, such as omrsysinfo_cgroup_get_memlimit, to work properly. This is because when running in a docker container, the cgroups listed in /proc/self/cgroup do not match the cgroups of the process in the container. /proc/self/cgroup actually shows the cgroups as seen from the host. Eg if a process is running in a docker container, its /proc/PID/cgroup on docker will show something like: $ cat /proc/8364/cgroup 11:cpuset:/docker/<container id> 10:perf_event:/docker/<container id> 9:memory:/dockera/<container id> ... but the actual cgroup of the process would be "/". Once we figure out that we are running in docker container, then cgroup APIs in port library would use "/" as cgroup name for reading resource limits. Note that as and when docker containers start supporting cgroup namespace, then above mentioned mismatch would also be fixed. Following issues and PRs are related to adding support for cgroup namespace in docker container: opencontainers/runc#1184 opencontainers/runtime-spec#62 opencontainers/runtime-spec#66 There is no direct mechanism to detect if we are running in docker container. Most reliable mechanism that I have come across is by checking the cgroup for PID 1 (by reading /proc/1/cgroup file) for all subsystems. If all cgroups are "/", then it indicates the process is running on host system. Else we conclude it to be running in a docker container. Note that this mechanism will break when docker containers start supporting cgroup namespace. Signed-off-by: Ashutosh Mehra <asmehra1@in.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue has been created to continue the discussion in #65
The text was updated successfully, but these errors were encountered: