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.

Sign up for GitHub

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

Jump to bottom

pod inspect cgrouppath broken under cgroups v1 #15027

Closed
edsantiago opened this issue Jul 21, 2022 · 2 comments
Closed

pod inspect cgrouppath broken under cgroups v1 #15027

edsantiago opened this issue Jul 21, 2022 · 2 comments
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@edsantiago
Copy link
Member

System test failure under cgroups v1 with runc:

[+1061s] not ok 262 pod resource limits
...
# podman pod inspect --format {{.CgroupPath}} resources1
machine.slice/machine-libpod_pod_d45f0976ba9dc9a753a348f90476d73ee8515a507a72784c5db4f8c5ce574ee0.slice
/var/tmp/go/src/github.com/containers/podman/test/system/200-pod.bats: line 486: /sys/fs/cgroup/machine.slice/machine-libpod_pod_d45f0976ba9dc9a753a348f90476d73ee8515a507a72784c5db4f8c5ce574ee0.slice/cpu.max: No such file or directory
#/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#|     FAIL: resource limits set properly
#| expected: '500000 100000'
#|   actual: ''
#\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@cdoern
Copy link
Contributor

cdoern commented Jul 21, 2022 •
edited
Loading

@edsantiago I will address this in my PR. we need to skip this test if v1, these resource limits are not supported in v1 mostly.

that file is not meant to exist in v1

@edsantiago edsantiago mentioned this issue Jul 21, 2022
Merged
edsantiago added a commit to edsantiago/libpod that referenced this issue Jul 22, 2022
@edsantiago
Bump VMs, to Ubuntu 2204 with cgroups v1
0a160fe 
...and enable the at-test-time confirmation, the one that
double-checks that if CI requests runc we actually use runc.
This exposed a nasty surprise in our setup: there are steps to
define $OCI_RUNTIME, but that's actually a total fakeout!
OCI_RUNTIME is used only in e2e tests, it has no effect
whatsoever on actual podman itself as invoked via command
line such as in system tests. Solution: use containers.conf

Given how fragile all this runtime stuff is, I've also added
new tests (e2e and system) that will check $CI_DESIRED_RUNTIME.

Image source: containers/automation_images#146

Since we haven't actually been testing with runc, we need
to fix a few tests:

  - handle an error-message change (make it work in both crun and runc)
  - skip one system test, "survive service stop", that doesn't
    work with runc and I don't think we care.

...and skip a bunch, filing issues for each:

  - containers#15013 pod create --share-parent
  - containers#15014 timeout in dd
  - containers#15015 checkpoint tests time out under $CONTAINER
  - containers#15017 networking timeout with registry
  - containers#15018 restore --pod gripes about missing --pod
  - containers#15025 run --uidmap broken
  - containers#15027 pod inspect cgrouppath broken
  - ...and a bunch more ("podman pause") that probably don't
    even merit filing an issue.

Also, use /dev/urandom in one test (was: /dev/random) because
the test is timing out and /dev/urandom does not block. (But
the test is still timing out anyway, even with this change)

Also, as part of the VM switch we are now using go 1.18 (up
from 1.17) and this broke the gitlab tests. Thanks to @Luap99
for a quick fix.

Also, slight tweak to containers#15021: include the timeout value, and
reword message so command string is at end.

Also, fixed a misspelling in a test name.

Fixes: containers#14833

Signed-off-by: Ed Santiago <santiago@redhat.com>
@cdoern
Copy link
Contributor

cdoern commented Jul 22, 2022

closing this, as it is not an issue with inspect but an issue with the cgroup path in the test.

@cdoern cdoern closed this as completed Jul 22, 2022
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@edsantiago @cdoern