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
Orphaned fuse-overlayfs processes (mount_program) #1654
Comments
@giuseppe PTAL |
what is the reason of using |
Mostly because it was an attempt to get the functionality (described in linked article) without having to configure it for every single user one by one, before discovering that Are you saying this is the cause of the problem? If so, can you please explain, as the problem does not occur on containers launched by root, and in the example shown above, root is not used. |
no, that is not the cause of the problem, fuse-overlays should work from root as well. The error is probably in the cleanup process, that doesn't trigger the unmount for the FUSE mount so the fuse-overlayfs process keeps running. Another thing worth noticing, Since you are always able to reproduce, would it be possible for you to run |
Tried with
There are no containers running.
Yes |
does it exist with containers that you create from this session or older ones? |
So I was basically doing the same thing as explained in this guide, setting in
/etc/containers/storage.conf
to:However this results in a
fuse-overlayfs
process spawning, and then never being terminated, even after the container using it has been removed.For example:
Running on debian bullseye with the packages built from https://gitlab.com/rhcontainerbot/rpms-openqa using debbuild
My complete
/etc/containers/storage.conf
:Edit:
Oh, I also forgot there's a per-user storage.conf for
gitlab-runner
:The text was updated successfully, but these errors were encountered: