On Mon, Jan 19, 2015 at 08:54:52PM +0300, Andrei Borzenkov wrote: > > What is causing this behavior? I have tried to replicate it by hand through > > a > > combination of mount and unshare, and the only way I can get a mount to > > persist > > in the unshare namespace after being unmounted in the global namespace is by > > explicitly calling mount `--make-rprivate /` *inside* the unshare > > namespace, which > > is obviously not happening in the above Docker example. > > > > It obviously happens. Your mount is private (it does not have any of > shared/master/.. flags). May be docker does it?
I think you may not have read the above correctly...with the Docker
exmaple, I am never explicitly using "--make-rprivate" in the child
mount namespace that I create with 'unshare'.
Docker may indeed be creating private mounts, but I can't replicate
that behavior myself doing something like:
global# mount --make-private /dev/testvol /mnt
In this case, if I create a new namespace with 'unshare -m', I see:
unshar# grep testvol /proc/self/mountinfo
860 749 253:16 / /mnt rw,relatime - ext4 /dev/mapper/fedora-testvol
rw,seclabel,data=ordered
And if I unmount the filesystem from the global namespace:
global# umount /mnt
It disappears from the "unshare" namespace as well:
unshare# grep testvol /proc/self/mountinfo
unshare#
If you can produce a sequence that replicates the behavior I'm seeing
with docker using just 'mount' and 'unshare' that would help
tremendously, because I'm still not entirely sure how we end up in
this state.
--
Lars Kellogg-Stedman <[email protected]> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpDxjun8R0RR.pgp
Description: PGP signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
