8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container

[jerboaa]

Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (podman, docker, crio), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:

[0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present

This state is being exposed by the Java Metrics API class using the new (still JDK internal) isContainerized() method. Example:

java -XshowSettings:system --version
Operating System Metrics:
    Provider: cgroupv1
    System not containerized.
openjdk 23-internal 2024-09-17
OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)

The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that OSContainer::is_containerized() == true in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.

Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.

Testing:

• GHA (risc-v failure seems infra related)
• Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
• Some manual testing using cri-o

Thoughts?

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18201/head:pull/18201
$ git checkout pull/18201

Update a local copy of the PR:
$ git checkout pull/18201
$ git pull https://git.openjdk.org/jdk.git pull/18201/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18201

View PR using the GUI difftool:
$ git pr show -t 18201

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18201.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back sgehwolf! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@jerboaa The following labels will be automatically applied to this pull request:

• core-libs
• hotspot
• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 02: Full - Incremental (434430ca)
• 01: Full - Incremental (0df26ebd)
• 00: Full (98325f18)

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[jerboaa]

Anyone willing to review this?

[jerboaa]

Gentle ping.

[jankratochvil]

IMHO is_containerized() is OK to return false even when running in a container but with no limitations set.

Container detection is IIUC/AFAIK being used to maximize resource usage by OpenJDK. But if OpenJDK runs in a container with the same limits as the hardware box OpenJDK should still use reduced resources as it is sharing them with other processes on the hardware box.

is-containerized.patch.txt

[jerboaa]

IMHO is_containerized() is OK to return false even when running in a container but with no limitations set.

The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when -XX:-UseContainerSupport should be used.

[tstuefe]

I am not enough of a container expert to judge if the basic approach is right - I trust you on this. This is just a technical code review.

[jankratochvil]

The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.

The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.

In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.

I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.

If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when -XX:-UseContainerSupport should be used.

That behaves still the same with my patch.

Could you give a countercase where my patch behaves wrongly?

[jerboaa]

@jankratochvil I believe this boils down to what we actually want. Should OSContainer::is_containerized() return false when run inside a container? If so, when is it OK to do that? Should OSContainer::is_containerized() return true on a physical Linux deployment? IMO, the read-only property of the mount points was something that fit naturally since, we already scan those anyway for (cgv1 vs cgv2 detection). Therefore it was something to consider to make heuristics more accurate.

The truth table of the patch in this PR looks like this:

OSContainer::is_containerized() value	Actual deployment scenario
true	OpenJDK runs in an unprivileged container without a cpu/memory limit
true	OpenJDK runs in an unprivileged container with a cpu/memory limit
true	OpenJDK runs in a privileged container with a cpu/memory limit
false	OpenJDK runs in a privileged container without a cpu/memory limit
false	OpenJDK runs in a systemd slice without a cpu/memory limit
true	OpenJDK runs in a systemd slice with a cpu/memory limit
false	OpenJDK runs on a physical Linux system (VM or bare metal)

As you can see, the case of "OpenJDK runs in a privileged container without a cpu/memory limit" gives the wrong result. However, I consider this a fairly uncommon setup and there isn't really anything we can do to detect this kind of setup. Even if we did manage to detect it, why would we care? It's a question of probability.

Could you give a countercase where my patch behaves wrongly?

Again, it's not a case of right or wrong IMO. Since we are in the land of heuristics, they will be wrong in some cases. We should make them so that we cover the common cases and, perhaps, are able to use those in serviceability tools to help guide diagnosis and/or further tuning. So far the existing capabilities were OK, but prevent further out-of-the-box tuning and/or accurate data collection.

Your proposed patch (it's one I had in a previous iteration too, fwiw) would also return false for the case of "OpenJDK runs in an unprivileged container without a cpu/memory limit", which seems counterintuitive if OpenJDK actually runs in a container! What's more, it seems a fairly common case. Also, there is a chance of the OpenJDK heuristics to fail memory/cpu limit detection because of bugs and new developments. It seems the safer option to know that OpenJDK is containerized (using other heuristics) in that case. Maybe that's just me.

Let's have that discussion more broadly and see if we can reach consensus!

[jankratochvil]

Could not we rename is_containerized() to use_container_limit() ? As that is the current only purpose of is_containerized().

I did not test it but I expect the values will be:

your patch	my trivial patch	Actual deployment scenario
true	false	OpenJDK runs in an unprivileged container without a cpu/memory limit
true	true	OpenJDK runs in an unprivileged container with a cpu/memory limit
false	false	OpenJDK runs in a privileged container without a cpu/memory limit
true	true	OpenJDK runs in a privileged container with a cpu/memory limit
false	false	OpenJDK runs in a systemd slice without a cpu/memory limit
true	true	OpenJDK runs in a systemd slice with a cpu/memory limit
false	false	OpenJDK runs on a physical Linux system (VM or bare metal)

[jerboaa]

Could not we rename is_containerized() to use_container_limit() ? As that is the current only purpose of is_containerized().

I'm not sure. There is value to have is_containerized() like it would behave after this patch. Specifically the first table row difference in your comment concerns me. JVMs running in a container without limit wouldn't be detected as "containerized". That seems a large share of deployments to miss.

[mlbridge]

Mailing list message from Laurence Cable on serviceability-dev:

On 4/18/24 9:38 AM, Severin Gehwolf wrote:

On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

Could not we rename `is_containerized()` to `use_container_limit()` ? As that is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()` like it would behave after this patch. Specifically the first table row difference in [your comment](https://github.com//pull/18201#issuecomment-2063868908) concerns me. JVMs running in a container without limit wouldn't be detected as "containerized". That seems a large share of deployments to miss.

agree 100%

[mlbridge]

Mailing list message from Laurence Cable on serviceability-dev:

On 4/18/24 2:54 AM, Severin Gehwolf wrote:

On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.
The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.
The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.

In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.
I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.

If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
That behaves still the same with my patch.

Could you give a countercase where my patch behaves wrongly?
@jankratochvil I believe this boils down to what we actually want. Should `OSContainer::is_containerized()` return `false` when run *inside* a container? If so, when is it OK to do that? Should `OSContainer::is_containerized()` return `true` on a physical Linux deployment? IMO, the read-only property of the mount points was something that fit naturally since, we already scan those anyway for (cgv1 vs cgv2 detection). Therefore it was something to consider to make heuristics more accurate.

The truth table of the patch in this PR looks like this:
| `OSContainer::is_containerized()` value | Actual deployment scenario |
| ------------- | ------------- |
| `true` | OpenJDK runs in an unprivileged container **without** a cpu/memory limit |
| `true` | OpenJDK runs in an unprivileged container **with** a cpu/memory limit |
| `true` | OpenJDK runs in a privileged container **with** a cpu/memory limit |
| `false` | OpenJDK runs in a privileged container **without** a cpu/memory limit |
| `false` | OpenJDK runs in a systemd slice **without** a cpu/memory limit |
| `true` | OpenJDK runs in a systemd slice **with** a cpu/memory limit |
| `false` | OpenJDK runs on a physical Linux system (VM or bare metal) |

As you can see, the case of "OpenJDK runs in a privileged container *without* a cpu/memory limit" gives the wrong result. However, I consider this a fairly uncommon setup and there isn't really anything we can do to detect this kind of setup. Even if we did manage to detect it, why would we care? It's a question of probability.

Could you give a countercase where my patch behaves wrongly?
Again, it's not a case of right or wrong IMO. Since we are in the land of heuristics, they will be wrong in some cases. We should make them so that we cover the common cases and, perhaps, are able to use those in serviceability tools to help guide diagnosis and/or further tuning. So far the existing capabilities were OK, but prevent further out-of-the-box tuning and/or accurate data collection.

I think (I am agreeing with you Severin) that the goal of the heuristic
is to inform the JVM (and any associated serviceability tools) that the
JVM is in a resource constrained/managed execution context...

Rgds

- Larry

[jerboaa]

Thanks for your input Larry!

[jankratochvil]

I think (I am agreeing with you Severin) that the goal of the heuristic is to inform the JVM (and any associated serviceability tools) that the JVM is in a resource constrained/managed execution context...

"resource constrained" (my patch) vs. "managed" (this patch) is the difference of the two patches being discussed.

Anyway in this patch one could unify naming across variables/parameters, the same value is called _is_ro, is_read_only, ro_opt, read_only, ro.

[jerboaa]

Anyway in this patch one could unify naming across variables/parameters, the same value is called _is_ro, is_read_only, ro_opt, read_only, ro.

I've tried to unify the naming a bit. Thanks for the review!