-
Notifications
You must be signed in to change notification settings - Fork 246
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
Fail on unmount/rmdir in overlay.Driver.Put #1607
Conversation
I have filed containers/podman#18634 to trigger a Podman test run at least, to see if there is something very obvious I’m missing. |
36c85d0
to
19fdd6e
Compare
instead of only logging a debug-level failure. We are seeing layers being mounted while our metadata claims that they are unmounted, and this seems to be a way how that could happen without leaving a visible trace. It's unclear to me why this silently succeeds; this behavior is very long-standing. Signed-off-by: Miloslav Trmač <[email protected]>
19fdd6e
to
da0df59
Compare
@giuseppe PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know how these failures could happen, since it is performing a lazy umount, but I agree it is better to know if something goes wrong so we know what to look at.
LGTM
I don’t know that either, but I am seeing EINVAL on unmount in containers/podman#18634 . (At this point I have no idea whether that’s a long-standing bug to be fixed, a failure that should be ignored, or a short-term fallout of some unrelated bug.) |
Nerf the bloat check, this PR is testing-only Signed-off-by: Miloslav Trmač <[email protected]>
LGTM |
A c/storage PR[1] chnage the behavior to correctly report umount errors. This is causing problem in the updgrade tests. The problem is that a cotnainer is mounted inside another container and then unmounted on the host. Therefore both operations happen in different mount namespaces. this is expcted but we want to share the mounts between them. This is the default but c/stroage make the root private by default thus the mounts were not shared. To fix this use the `skip_mount_home` storage option so the mount is kept shared. [1] containers/storage#1607 Signed-off-by: Paul Holzinger <[email protected]>
It seems there are cases where underlying layers can be already unmounted in such case the layer directory is not removed and put fails early with `EINVAL` causing dangling directory for these layers. Following case may be a hidden underlying issue with `unmounting` of `c/stoage` which needs more investigation however prior discussion shows that this is a long standing issue in `storage` and which was never caught till containers#1607 Signed-off-by: Aditya R <[email protected]>
It seems there are cases where underlying layers can be already unmounted in such case the layer directory is not removed and put fails early with `EINVAL` causing dangling directory for these layers. Following case may be a hidden underlying issue with `unmounting` of `c/stoage` which needs more investigation however prior discussion shows that this is a long standing issue in `storage` and which was never caught till containers#1607 Signed-off-by: Aditya R <[email protected]>
… instead of only logging a debug-level failure.
We are seeing layers being mounted while our metadata claims that they are unmounted, and this seems to be a way how that could happen without leaving a visible trace.
It's unclear to me why this silently succeeds; this behavior is very long-standing.
Motivated by containers/podman#17216 , where we seem to be seeing mounted layers with zero count in
mount points.json
.Debug
logs to be elevated to at least aWarning
, possibly outrightError
. @nalind @giuseppe PTAL.