Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/sys/fs/cgroup/memory/memory.limit_in_bytes is missing in the container in version > 4.2.0 #6118

Closed
3 tasks done
gtskaushik opened this issue Jan 2, 2022 · 6 comments
Closed
3 tasks done

Comments

@gtskaushik
Copy link

  • I have tried with the latest version of Docker Desktop
  • I have tried disabling enabled experimental features
  • But the same is working in version 4.2.0

Expected behavior

This file needs to be present inside the container which denotes the total available memory for the container. In this case, I had set the limits to 500mb
File name - /sys/fs/cgroup/memory/memory.limit_in_bytes is missing
File contents - 524288000

Actual behavior

In versions above 4.2.0, the directory, "/sys/fs/cgroup/memory" is missing in the containers. So, runtimes like java is not able use the container aware logics which relies on this.

Information

  • Is it reproducible? Yes
  • Is the problem new? Yes
  • Did the problem appear with an update? Yes. post 4.2.0
  • macOS Version:
  • Intel chip or Apple chip: Intel
  • Docker Desktop Version: > 4.2.0

Steps to reproduce the behavior

  1. Download and install the latest docker for mac version which is greater than 4.2.0
  2. docker run -it --rm ubuntu bash
  3. cat /sys/fs/cgroup/memory/memory.limit_in_bytes
  4. Step 3 should show the memory allocated to docker for mac as no limits were set. But the file is missing
@zhangs-ibm
Copy link

Got exactly the same issue at docker desktop 4.3.2, docker server version info:

Server: Docker Engine - Community
 Engine:
 Version:     20.10.11
 API version:   1.41 (minimum version 1.12)
 Go version:    go1.16.9
 Git commit:    847da18
 Built:      Thu Nov 18 00:35:39 2021
 OS/Arch:     linux/amd64
 Experimental:   false
 containerd:
 Version:     1.4.12
 GitCommit:    7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
 Version:     1.0.2
 GitCommit:    v1.0.2-0-g52b36a2
 docker-init:
 Version:     0.19.0
 GitCommit:    de40ad0

This issue break Open J9 feature -XX:[+|-]UseContainerSupport immediately: https://www.eclipse.org/openj9/docs/xxusecontainersupport/

@djs55
Copy link
Contributor

djs55 commented Jan 6, 2022

@gtskaushik @zhangs-ibm Thanks for the ticket. Recent versions of Docker Desktop switched to cgroupv2 by default. From the linked ticket ibmruntimes/ci.docker#124 it looks like some Java runtime versions only support cgroupv1.

I think the options are:

  1. update the Java runtime to a version which supports cgroupv2
  2. temporarily switch back to cgroupv1 in Docker Desktop by setting the switch mentioned here: Unable to run systemd services on Docker Desktop 4.3.0 #6073 (comment)

Note that some future Docker Desktop features might not work in cgroupv1 mode: this is because new features for the Linux kernel are only being added to cgroupv2. If you use cgroupv1 mode, I recommend asking your Java vendor to add support for cgroupv2.

@gtskaushik
Copy link
Author

Thanks @djs55
Looks like only from Java 15, the cgroup v2 detection is possible.
https://bugs.openjdk.java.net/browse/JDK-8230305?subTaskView=unresolved

Moved to the dev docker and used this as mentioned in the link above.

"legacyCgroupv1": true

It is working now. Thanks. Is there any timeline on when this will be available for the main builds

@djs55
Copy link
Contributor

djs55 commented Jan 6, 2022

@gtskaushik thanks for the update. We're hoping to release an official build next week. In the official build the field is renamed to deprecatedCgroupv1 but I'll mention this in the release notes and update the various tickets.

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Jun 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants