Adapt to cgroup v2 version

[cqmmm]

When we created a RocketMQ cluster on an Ubuntu 22.04, the controller encountered this error. We found that starting from Ubuntu 21.10, cgroup v2 is used by default, and many Java applications need to be adapted. I believe it's necessary to make this adaptation. Currently, we resolved it by downgrading the cgroup version to v1.

[asjfoajs]

可以看一下#198

[zhihui921016]

您好，您的邮件我已经收到。

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Needs Verification

Thank you for reporting this issue. To proceed with verification, please provide:

• Version/tag or commit hash where this occurs
• Steps to reproduce
• Expected vs actual behavior
• Relevant logs or stack traces

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Adapting RocketMQ to cgroup v2 is a valid and timely enhancement. As Kubernetes distributions increasingly default to cgroup v2 (K8s 1.25+), the JVM and native processes inside RocketMQ containers need to correctly read resource limits from the cgroup v2 hierarchy.

Feasibility: feasible — primarily involves updating JVM flags (-XX:+UseContainerSupport is default in JDK 10+) and verifying that broker/store memory calculations respect cgroup v2 limits.
Scope: Dockerfile, JVM startup scripts, operator resource limit handling
Compatibility: Should be backward-compatible with cgroup v1 environments.

This is a valuable improvement for modern Kubernetes deployments.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: feasible
Scope: Broker container image and resource configuration
Compatibility: Needs to handle both cgroup v1 and v2 environments.

With the Linux kernel moving to cgroup v2 as the default (Ubuntu 22.04+, RHEL 9+), the RocketMQ Operator and Broker images need to support cgroup v2 for correct resource limit detection.

The JVM inside the Broker container reads cgroup v1 paths (/sys/fs/cgroup/memory/...) for memory limits. On cgroup v2 systems, these paths don't exist, causing the JVM to fall back to host-level resource detection.

This requires:

• Updating the JVM flags to use -XX:+UseContainerSupport (Java 11+)
• Ensuring the Broker startup script detects cgroup version
• Testing on both cgroup v1 and v2 nodes

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Hi @cqmmm! 👋

Thanks for your contribution. This issue has been noted and flagged for maintainer triage.

---

🤖 Automated issue analysis by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: Feasible
Scope: Docker image / JVM startup scripts
Compatibility: Non-breaking — JVM arguments for cgroup v2 are backward compatible with newer JDK versions.

Valid enhancement. Ubuntu 22.04+ and other modern distros use cgroup v2 by default. Java applications (especially older JDK versions) need explicit cgroup v2 support via JVM flags (-XX:+UseContainerSupport in JDK 11+).

Suggested fix: Update the Docker image entrypoint to detect cgroup v2 and add appropriate JVM flags. Consider upgrading the base JDK to 11+ which has better cgroup v2 support.

---

Automated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Adapting to cgroup v2 is a valid and increasingly important enhancement. Ubuntu 22.04+ and newer Kubernetes distributions use cgroup v2 by default, and Java applications need proper cgroup awareness for correct resource limits.

Feasibility: Feasible — Java 11+ has cgroup v2 support via -XX:+UseContainerSupport, but the operator scripts and Docker images may need updates.
Scope: Docker images, startup scripts, and JVM options in the operator.
Compatibility: Should be backward compatible with cgroup v1 systems.

---

Automated evaluation by RockteMQ-AI