Move docker cgroup override to SystemJvmOptions (#85960)

The system jvm options are those that Elasticsearch always adds to the
ES java command line. In docker, a hack exists for cgroups, which is
passed through the user's ES_JAVA_OPTS. This commit moves the processing
of that docker hack to the system jvm options.

relates #85758

distribution/src/bin/elasticsearch

@@ -96,7 +96,7 @@ fi
 #   - second, JVM options are read from jvm.options and jvm.options.d/*.options
 #   - third, JVM options from ES_JAVA_OPTS are applied
 #   - fourth, ergonomic JVM options are applied
-ES_JAVA_OPTS=`export ES_TMPDIR; "$JAVA" -cp "$LAUNCHERS_CLASSPATH" org.elasticsearch.tools.launchers.JvmOptionsParser "$ES_PATH_CONF" "$ES_HOME/plugins"`
+ES_JAVA_OPTS=`export ES_TMPDIR; "$JAVA" -cp "$LAUNCHERS_CLASSPATH" -Des.distribution.type="$ES_DISTRIBUTION_TYPE" org.elasticsearch.tools.launchers.JvmOptionsParser "$ES_PATH_CONF" "$ES_HOME/plugins"`
 
 # Remove enrollment related parameters before passing the arg list to Elasticsearch
 for i in "${!ARG_LIST[@]}"; do

distribution/src/bin/elasticsearch-env

@@ -91,21 +91,4 @@ ES_PATH_CONF=`cd "$ES_PATH_CONF"; pwd`
 
 ES_DISTRIBUTION_TYPE=@es.distribution.type@
 
-if [[ "$ES_DISTRIBUTION_TYPE" == "docker" ]]; then
-
-  # The virtual file /proc/self/cgroup should list the current cgroup
-  # membership. For each hierarchy, you can follow the cgroup path from
-  # this file to the cgroup filesystem (usually /sys/fs/cgroup/) and
-  # introspect the statistics for the cgroup for the given
-  # hierarchy. Alas, Docker breaks this by mounting the container
-  # statistics at the root while leaving the cgroup paths as the actual
-  # paths. Therefore, Elasticsearch provides a mechanism to override
-  # reading the cgroup path from /proc/self/cgroup and instead uses the
-  # cgroup path defined the JVM system property
-  # es.cgroups.hierarchy.override. Therefore, we set this value here so
-  # that cgroup statistics are available for the container this process
-  # will run in.
-  export ES_JAVA_OPTS="-Des.cgroups.hierarchy.override=/ $ES_JAVA_OPTS"
-fi
-
 cd "$ES_HOME"

distribution/tools/launchers/src/main/java/org/elasticsearch/tools/launchers/SystemJvmOptions.java

@@ -61,7 +61,29 @@ final class SystemJvmOptions {
              *
              * TODO: either modularlize Elasticsearch so that we can limit the opening of this module, or find an alternative
              */
-            "--add-opens=java.base/java.io=ALL-UNNAMED"
+            "--add-opens=java.base/java.io=ALL-UNNAMED",
+            maybeOverrideDockerCgroup()
         ).stream().filter(e -> e.isEmpty() == false).collect(Collectors.toList());
     }
+
+    /*
+     * The virtual file /proc/self/cgroup should list the current cgroup
+     * membership. For each hierarchy, you can follow the cgroup path from
+     * this file to the cgroup filesystem (usually /sys/fs/cgroup/) and
+     * introspect the statistics for the cgroup for the given
+     * hierarchy. Alas, Docker breaks this by mounting the container
+     * statistics at the root while leaving the cgroup paths as the actual
+     * paths. Therefore, Elasticsearch provides a mechanism to override
+     * reading the cgroup path from /proc/self/cgroup and instead uses the
+     * cgroup path defined the JVM system property
+     * es.cgroups.hierarchy.override. Therefore, we set this value here so
+     * that cgroup statistics are available for the container this process
+     * will run in.
+     */
+    private static String maybeOverrideDockerCgroup() {
+        if ("docker".equals(System.getProperty("es.distribution.type"))) {
+            return "-Des.cgroups.hierarchy.override=/";
+        }
+        return "";
+    }
 }