RFR: 8264482: container info misleads on non-container environment [v2]

David Holmes dholmes at openjdk.java.net
Tue Apr 6 01:42:29 UTC 2021


On Thu, 1 Apr 2021 13:03:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> hs_err log and `VM.info` dcmd shows cgroup information as container information even though the process run on non-container environment as following.
>> 
>> container (cgroup) information:
>> container_type: cgroupv2
>> cpu_cpuset_cpus: not supported
>> cpu_memory_nodes: not supported
>> active_processor_count: 4
>> cpu_quota: not supported
>> cpu_period: not supported
>> cpu_shares: not supported
>> memory_limit_in_bytes: unlimited
>> memory_and_swap_limit_in_bytes: unlimited
>> memory_soft_limit_in_bytes: unlimited
>> memory_usage_in_bytes: 164163584
>> memory_max_usage_in_bytes: not supported
>> 
>> We can use cgroup outside of container, so it is useful to show. However cgroup is different from container. We should distinguish them.
>> And also it is useful if we can see container runtime in this section. So I added it. We can see following contents in this section after this change.
>> 
>> cgroup information:
>> cgroup_type: cgroupv2
>> container runtime: podman
>> cpu_cpuset_cpus: not supported
>> cpu_memory_nodes: not supported
>> active_processor_count: 4
>> cpu_quota: not supported
>> cpu_period: not supported
>> cpu_shares: not supported
>> memory_limit_in_bytes: unlimited
>> memory_and_swap_limit_in_bytes: unlimited
>> memory_soft_limit_in_bytes: unlimited
>> memory_usage_in_bytes: 256176128
>> memory_max_usage_in_bytes: not supported
>> 
>> In case of systemd, it checks PID (PID 1 or not) and `$container` in PID 1. We should check them to know the JVM runs on the container or not.
>> 
>> https://github.com/systemd/systemd/blob/68337e55f62cf49b7bdfb73dc5662e23b0ea17fa/src/basic/virt.c#L619
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove code to detect container runtime

Sorry Yasumasa but I don't agree with this. OSContainer is supposed to be the abstraction representing a containerized environment. Calling code doesn't know (nor care) what the underlying mechanism is - maybe it is cgroups, maybe it isn't. If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO.

David

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3280


More information about the hotspot-runtime-dev mailing list