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

cgroupfs support #800

Open
davidkopp opened this issue Jun 2, 2024 · 2 comments
Open

cgroupfs support #800

davidkopp opened this issue Jun 2, 2024 · 2 comments

Comments

@davidkopp
Copy link
Contributor

I tried to get cgroup v2 running under Windows with WSL2. This issue is intended to document my experiences with it so far.

cgroup v2 can generally be activated in WSL (see below), but its use in GMT currently fails because Docker Desktop on Windows uses the cgroup driver cgroupfs, but GMT only supports cgroup v2 with the cgroup driver systemd. Helpful information about the two cgroup drivers can be found here.

I can think of three ways, how the usage of cgroups in WSL could be possible:

  • GMT supports the cgroupfs driver
  • Docker is installed directly in WSL, without Docker Desktop, and started with systemd (not tested)
  • GMT supports cgroup v1 (cgroups v1 support #497)

The problem is not really important to me. But I thought it would make sense to document it here quickly.


How to activate cgroup v2 in WSL?

Create the file %USERPROFILE%\.wslconfig (or edit it) and add the following content:

[wsl2]
kernelCommandLine = systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all

Source: Docker Desktop 4.17.0 Release Notes

Then restart WSL (wsl.exe --shutdown).
You can check which cgroup version is activated via:

mount -l | grep cgroup
@ArneTR
Copy link
Member

ArneTR commented Jun 6, 2024

Generally we have that support already lingering as in Github Codespaces we also encountered older cgroup drivers and have migrated the cgroup providers to work there.

The relevant code to identify the fileystem paths is here: https://github.com/green-coding-solutions/green-metrics-tool/blob/da82f39f823d351a919c1c58d53f33c3cdc58e99/metric_providers/cpu/utilization/cgroup/container/source.c#L138C9-L158C1

Effectively it would have to be moved to the domain that docker is setting for the created containers.

To advance this issue a little: Can you post a ls -alhR /sys/fs/cgroup of your system when the containers from Docker Desktop are running?

@davidkopp
Copy link
Contributor Author

Ah, I should have investigated the issue more closely. The cause for my issue seems to be, that the cgroup directory of the container is named exactly like the container ID on my system, without any prefix or suffix. GMT looks for the pattern /sys/fs/cgroup/system.slice/docker-%s.scope/cpu.stat, however, to find it on my system it should probably be /sys/fs/cgroup/system.slice/%s/cpu.stat (untested).

Full output of the ls command:
https://gist.github.com/davidkopp/537570322f928e17e7ac9c910ae32f2c

Error:

RuntimeError: Stderr on CpuUtilizationCgroupContainerProvider was NOT empty: Error - Could not open path for reading: /sys/fs/cgroup/system.slice/docker-9fa3b5065779c9c2679ee816b73242b7d549d767b16d67804d8cfeb82f7402ee.scope/cpu.stat. Maybe the container is not running anymore? Are you using --rootless mode? Errno: 2

In the gist you can find the directory /sys/fs/cgroup/system.slice/9fa3b5065779c9c2679ee816b73242b7d549d767b16d67804d8cfeb82f7402ee.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants