-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Flake: Deleting pod: something-cgroup-conmon: EBUSY #14057
Comments
It solves a race where a container cleanup process launched because of the container process exiting normally would hang. It also solves a problem when running as rootless on cgroup v1 since it is not possible to force pids.max = 1 on conmon to limit spawning the cleanup process. Partially copied from containers#13403 Related to: containers#14057 [NO NEW TESTS NEEDED] it doesn't add any new functionality Signed-off-by: Giuseppe Scrivano <[email protected]>
not sure it is the right fix, since I wasn't able to reproduce locally, but there is one race condition I am aware of in the pod cleanup code: #14061 |
@edsantiago have you seen it flake after #14061? |
No, but only three PRs have merged since then. |
Yep, still happening (f36 root, PR is based on very-latest main) |
f35 root too, in a different test |
if the cgroup cleanup fails with EBUSY, attempt to kill the processes. Related to: containers/podman#14057 Signed-off-by: Giuseppe Scrivano <[email protected]>
let's also kill the processes contained in the cgroup, in the same way as the systemd backend does: containers/common#1019 A bigger hammer, but I think it solves the race condition we are observing |
if the cgroup cleanup fails with EBUSY, attempt to kill the processes. Related to: containers/podman#14057 Signed-off-by: Giuseppe Scrivano <[email protected]>
When containers/common gets merged into Podman we can close this issue. |
It solves a race where a container cleanup process launched because of the container process exiting normally would hang. It also solves a problem when running as rootless on cgroup v1 since it is not possible to force pids.max = 1 on conmon to limit spawning the cleanup process. Partially copied from containers#13403 Related to: containers#14057 [NO NEW TESTS NEEDED] it doesn't add any new functionality Signed-off-by: Giuseppe Scrivano <[email protected]>
Yep, jinxed myself yesterday.
Looks similar to #11946 but different enough to merit a new issue.
Seen just now in int f36 root on an in-flight PR; logs show it happening since April 2:
Podman play kube [It] podman play kube test env value from configmap and --replace should reuse the configmap volume
Entrypoint
to an array instead of a string #13811Podman play kube [It] podman play kube teardown
The text was updated successfully, but these errors were encountered: