-
Notifications
You must be signed in to change notification settings - Fork 175
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
Attached disks resource leak. #5372
Comments
github.com/vmware/vic/lib/portlayer/storage/vsphere/image.go:334
|
Pinging @matthewavery for estimate and priority. Temporarily removing high priority - please re-assess based on our criteria. |
Not only should it be unmounted and detached - we should be deleting the layer on disk so that we can re-pull. |
The problem is not at the code I pointed. There is a deferred call at the beginning that can do all this clean up, but it is a little obstructed and needs to be redesigned. As it happened the root cause is at mount point name that contains spaces on my side. Spaces are replaced by "\040" sequence in /proc/self/mountinfo that lead to string mismatch when we check if this mount point is actually mounted. Because there is no match (" " != "\040"), partition is not unmounted and it leads to a resource leak. |
@vburenin is this a theoretical problem for a port layer consumer, or could this manifest as a bug for a customer using VIC? Need to know how to prioritize for 1.2. |
@corrieb This is not a theoretical problem unfortunately. There is a bug in the vendored docker code of how unmount is handled. We either need to impose restrictions for image names not to include spaces or do not use user provided image names when stored in datastore. It went a little more far than this later during my containerd work. ESXi doesn't allow file names longer than 128 bytes, so I ended up using name hashes instead real image names to go through the situation when containerd wanted to use really long names over 200 bytes. |
Closing as resolved by PR #5373. |
User Statement:
I try to make a PortLayer call WriteImage that supposed to unpack content of an image into newly created VMDK. If there is an error happens, for example SHA256 mismatch, VMDK disks stays unmounted and not detached, that can easily cause resource leak and make VCH unusable.
For some reason, VMDK is mounted as read-only.
Acceptance Criteria:
Disk should be unmounted and detached in case of an error.
Logs
The text was updated successfully, but these errors were encountered: