-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Podman's vs Docker's approach to container id inspection in cgroup v2 environments #14236
Comments
@skepticoitusInteruptus podman expects there to be an initial group defined (normally done by systemd) so that it can propagate values from it. You should just be able to create a cgroup in /sys/fs/cgroup (e.g. mkdir /sys/fs/cgroup/mygroup), and then run podman under that cgroup |
Mucho Thanky-o, @n1hility. I will try that later today. In the meantime I will share where I'm at so far... Observations
Questions
|
It's a fair question. We could just skip the swap validation check in the case of a root v2 control group wdyt @giuseppe
This actually works for me with your reproducer. Did you try removing your .wslconfig settings and doing a wsl --shutdown first just to make sure its booting correctly? Are you doing this as root. (Rootless doesn't work with v1)
It's definitely not a hard requirement. In the past you might have had to set things like the cgroups manager to not use systemd |
Sincere thanks for your answers, @n1hility 👍
First, I manually added the shell I'm invoking
Then, I figured out the pid of the
Then, after establishing that pid
Then, I manually set the memory limits for the automatically-created
I still got the same error I originally reported though:
Trying to circumvent that, I tried
I'm 97% confident that my manual cgroup config took. That's based on the cgroup-related stuff I'm seeing in all the After each of the three different invocations above, The tell-tale cgroup v2 clues that are logged after every different permutation of
I forgot to mention that I did that particular cgroup v1 experiment in Docker Playground that time; not in my WSL2 Alpine locally. That error might be because Docker Playground's Alpine instances are on an old |
you're welcome!
Try this:
You should see the 6m value having an effect in the output. |
Can confirm 👍 I'm guessing that you were able to reproduce the error I originally described(?) So do your results establish anything regarding podman's behavior parity with Docker? By behavior parity, I mean If Thanks again for looking into this, @n1hility. Mucho helpfully-o! |
Yes it’s an excellent reproducer. Thank you.
Oh sure, I basically agreed on this point earlier that we could handle this case. I’ll try to throw up a pr tomorrow if I find some cycles.
You’re welcome! |
Related to containers/crun/issues/923 |
Thanks fellahs 👍 Given the absense of a response from @giuseppe to my question in @n1hility's PR, I'm gonna go ahead and infer the unspoken answer is probably:
I will note the findings of my spike in the documentation that will be presented to my team. Mucho Thanky-o 🙏 — 1 Other observations of Podman's cgroup v2-related behavior also suggest this is a reasonable inference |
Sorry I missed your question in the PR. This is essentially what I meant in #14236 (comment) I would word it a little differently though than from what you have above. I would say that the only known reliable swap controller detection mechanism with cgroupsv2 relied on a cgroup being present, and since a system using cgroups usually associates one with logins (either via systemd or something else) that didn't (yet) present as a problem. |
We're good @n1hility. I apprecicate it was neither your nor @giuseppe's highest priority. If either of you ever do get one or two free cycles, I'm curious to get some insight into how unreasonable my expectations are in this crun issue I reported last week.
I appreciate why in practice that would be an implementation detail for something like a Podman. I haven't been able to find any mention of any explicit login-related constraints on cgroup's expected general usage in the official cgroup v2 documentation, though. Muchas Thankias 🥇 |
Is this a BUG REPORT or FEATURE REQUEST?
/kind bug
Description
My spike:
My tests:
Steps to reproduce the issue:
%USERPROFILE%\.wlsconfig
to support cgroup v2:1-m
option:-m
option:Describe the results you received:
Describe the results you expected:
Additional information you deem important:
systemd
2/proc/self/cgroup
"Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes (v4.1.0)/Yes (none of the 35 common issues apply)
Additional environment details (AWS, VirtualBox, physical, etc.):
—
1 With WSL2 and Alpine configured for cgroup v2, based on an admixture of configurations suggested by @lightmelodies, configurations suggested by @nunix and MS' own Advanced settings in WSL
2 My requirements emphatically exclude any dependency on
systemd
The text was updated successfully, but these errors were encountered: