Garbage cleanup

[brianjmurrell]

Feature request description

Podman fills up my ~.

Suggest potential solution

I wonder if it would be appropriate for the podman packaging to include periodic (i.e. cron or systemd timer) garbage cleaners to remove unused containers and images. I seem to regularly need to do:

$ podman container prune; podman image prune

It would be nice to have this preventative action happen without the need for every individual to have to re-create it.

Have you considered any alternatives?

Of course, each individual solving this problem for themselves, but why should every podman user have to venture down this path, re-inventing wheels?

Additional context

No response

[rhatdan]

I would not have a problem with these services being defined and not enabled by default. Perhaps with reference in the prune man pages.

[brianjmurrell]

Given that this kind of garbage cleanup isn't something that you would enable by default makes me think that not everyone would want it which makes me wonder what I am doing wrong to cause so much garbage to pile up.

I am testing CI pipelines that use containers to do their work in, so repeatedly I run something along the lines of:

podman build --file Dockerfile --build-arg … --tag foo-build foo/
podman run --name foo-build-$unique" --privileged=true -e … foo-build bash -c "…"

which depending on the churn of the Dockerfile can lead to a lot of containers and images building up and fill up my ~. podman container prune; podman image prune manages to clean up the pile up of garbage.

But is there something I should be doing that would prevent the pile up?

[Luap99]

Given that this kind of garbage cleanup isn't something that you would enable by default

These thing can never turned on by default. How do we know just because a container is stopped that it should be removed? There could be data in there were a user care about...

In general shipping some systemd service + timer is fine but enabling that by default is not possible IMO as this will break many users one way or another.

[brianjmurrell]

These thing can never turned on by default. How do we know just because a container is stopped that it should be removed? There could be data in there were a user care about...

Fair enough. But then how should a machine that is a CI/CD runner that starts containers over and over again all day long, (i.e. 24x7) be starting and/or managing containers such that they do no pile up creating such a big garbage pile that it needs to be pruned periodically, if there can also be containers that should not be pruned because they may contain wanted data?

IOW, as it seems that pruning containers is a big hammer that can cause collateral damage, how should one be starting and/or managing containers so that they do not need to be pruned periodically? I.e how can I avoid the need to prune periodically? What am I doing wrong that is leaving so many containers around that they need to be pruned?

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Are you running your containers with the --rm switch? Are these containers being left behind because of system crashes or reboots? Are you killing contianers randomly in your CI/CD system preventing podman from cleaning them up?

[brianjmurrell]

Maybe it's a combination of more than one of those. I was indeed not using --rm when running containers. After adding that, I do observe that there are no containers remaining when I am done my pipeline.

However if I interrupt it while the containers are running, the containers remain left running afterward. Am I to understand that podman run --rm … doesn't clean up containers if it's SIGINTR'd the way it does when it's allowed to complete? Is there any way to have podman clean up containers even if interrupted or am I going to have to set up a post-podman run --rm job to clean those up if podman run --rm is interrupted?

I suppose of course I could just let the containers complete as they would have had I not interrupted podman run --rm but it seems wasteful to let them continue to run when I am clearly not interested in their result.

[dustymabe]

There's overlap here with #26191