podman image prune fixed, but podman system prune does not act recursively
#7990
Assignees
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
stale-issue
Comments
openshift-ci-robot
added
the
kind/bug
|
I cannot reproduce. @srcshelton, can you share a reproducer? For instance, a script you use to build the images. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Since we never got the reproducer, I am going to close. Reopen if new data becomes available. |
|
I'm not sure what more I can say here? Even with ... results in: |
|
That is not a reproducer, We see that your storage is screwed up. We need a mechanism to get a test storage into a similar state that we could then fix the prune code to clean it up. |
|
But I've not done anything other than use podman! I can try any test you suggest, but I'm not doing anything unusual that I know of, so I'm not sure what I can provide to help fix this! I'm obviously keen to get it fixed, but I'm afraid you're going to have to suggest what data you need, or what tests I can perform for you to move this forwards. Clearly, the problem is real - how can we work together to fix it? |
|
In more detail, I'm building containerised service applications (redis, mariadb, etc.) from source, using the Gentoo 'portage' build-system. This process involves a multi-stage base build-container which is run to compile the actual application, and exits even on successful completion. This container is then 'commit'ted to a temporary image, which is itself used in the 'FROM' clause of the 'build' stage of a new container with extracts the build-root from the provided image, and produces the intended service container. … so there's a fair amount of inter-dependencies in-fight - but nothing too unusual? |
|
This has been fixed in main branch. |
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Following from #7872, which made
podman image pruneact recursively, I noted that the fix did not seem to addresspodman system prune. This was met with some surprise, as the two (as would be expected) apparently share much of their code-paths. However, on an otherwise quiescent system with no image/container creation or destruction occurring:... at which point I updated my script to handle
system prunetoo:... so clearly the fix for
image prunehasn't applied correctly tosystem prune.Output of
podman version:N.B. This build of 2.1.1 has been patched with
1492f3c936a0f6180db61a6500371aceebc37e39("--rm option shold conflicts with --restart") and6c151b98b6d4d6a6d9acf64aaafdb5265d07932e("image prune: remove all candidates")Output of
podman info --debug:Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
The text was updated successfully, but these errors were encountered: