aardvark-dns locks mount points
#25994
Comments
|
I attempted to reproduce this on the latest main branch without success. I can't install zfs, OpenZFS don't ship arm64 builds so I made my attempt with tempfs. sudo mkdir /mnt/mytmp
sudo mount -t tmpfs -o size=1G tmpfs /mnt/mytmp
findmnt /mnt/mytmp
./bin/podman kube play ./foo.yaml
sudo umount /mnt/mytmp
findmnt /mnt/mytmpCould you also try with tmpfs? |
ninja-quokka
added
network
|
A reviewer has determined we need more information to understand the reported issue. A comment on what is missing should be provided. Be certain you:
If no response to the For more information on reporting issues on this repository, consult our issue guide. |
|
There might have been some confusion in my initial report.
The first step works fine, even with the container running. After running Hence, the To make this clearer to reproduce, I've also done the test with LVS. This is a bit more involved, but basically tests the same thing. Create a PV, a VG, and a LV, then format with XFS Mount the file system somewhere Note the Start the pod Unmount the file system on the host. Note that this succeeds. Looking at the LV, it is still open And it cannot be removed The LV is still open Stopping the container allows removal of the LV The warning is because the volume is still "active", but it is no longer "open". |
diff --git a/vendor/github.com/containers/common/libnetwork/internal/rootlessnetns/netns_linux.go b/vendor/github.com/containers/common/libnetwork/internal/rootlessnetns/netns_linux.go
index 2655587654..06ed3cb5b5 100644
--- a/vendor/github.com/containers/common/libnetwork/internal/rootlessnetns/netns_linux.go
+++ b/vendor/github.com/containers/common/libnetwork/internal/rootlessnetns/netns_linux.go
@@ -369,7 +369,7 @@ func (n *Netns) setupMounts() error {
// Ensure we mount private in our mountns to prevent accidentally
// overwriting the host mounts in case the default propagation is shared.
- err = unix.Mount("", "/", "", unix.MS_PRIVATE|unix.MS_REC, "")
+ err = unix.Mount("", "/", "", unix.MS_SLAVE|unix.MS_REC, "")
if err != nil {
return wrapError("make tree private in new mount namespace", err)
}Could you try building podman with this and test it? I think the private mount means that the umount on the host is not propagated into the rootless-netns mount namesapce so it stays mounted there I think. With salve the event should be propagated correctly. I can try to reproduce later, likely it would be best to use loop device for the lvm setup so the reproducer doesn't have to depend on an external device. |
|
I can try a build with that patch this evening (european time).
I'm a bit concerned about the comment directly above, this reads like
the `PRIVATE` was intentional?
|
I have tested my patch with this which seems to work so I will open a PR with it. private was intentional to avoid the mounts being shared which means the mounts in the rootless-netns namespace could propagate to the host, containers/common@4225302. |
Luap99
added
triaged
We don't want to leak our mounts to the host but we still like to to update mounts/umount events from the host. This is so when a fs is unmounted on the host we don't happen to keep it open in aardvark-dns. Fixes: containers/podman#25994 Fixes: 4225302 ("libnetwork/rootlessnetns: make mountns tree private") Signed-off-by: Paul Holzinger <[email protected]>
|
I rebuilt the podman version I had with this patch applied, and the
issue no longer appears.
|
We don't want to leak our mounts to the host but we still like to to update mounts/umount events from the host. This is so when a fs is unmounted on the host we don't happen to keep it open in aardvark-dns. Fixes: containers/podman#25994 Fixes: 4225302 ("libnetwork/rootlessnetns: make mountns tree private") Signed-off-by: Paul Holzinger <[email protected]>
Issue Description
Note: I'm not sure if this is a
podmanor anaardvark-dnsissue.Running
aardvark-dnsprocesses will block devices backing mount points (like partitions, logical volumes...) from being destroyed if the file system mounted from these devices were mounted whenaardvark-dnswas started. Theaardvark-dnsprocess must be terminated for the device to be freedSteps to reproduce the issue
Mote: I'm using
zfsfor demonstration purposes here, as this is easiest on the machine in question, but this is not a ZFS specific problem. The problem also manifests with partitions and logical volumes.All podman commands run as rootless.
Create a very simple pod that does not mount anything from the host:
Create a new file system on the host:
Note the file system is empty, it's not used by anything, it's just mounted.
Start the pod
Try to destroy the just-created file system
There are no users of that path
But the mount point is still held
Stop the pod
The file system can now be destroyed
Describe the results you received
Devices backing file systems that were mounted when
aardvark-dnswas started cannot be destroyed untilaardvark-dnsis stoppedDescribe the results you expected
Devices can be destroyed
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: