On Friday 05 April 2013 17:55:46 Lennart Poettering wrote: > On Tue, 02.04.13 10:27, Tvrtko Ursulin ([email protected]) wrote: > > You need to try it since you don't seem to believe me. :) > > > > + M1=testmp1 > > + M2=testmp2 > > + SM=submount > > + mkdir -p testmp1 > > + mkdir -p testmp2 > > + mount none -t tmpfs testmp1 > > + mkdir -p testmp1/submount > > + mount none -t tmpfs testmp1/submount > > + strace -f -e trace=mount,umount mount testmp1 --rbind testmp2 > > mount("/root/3/testmp1", "testmp2", 0x7f70e796a67c, > > MS_MGC_VAL|MS_BIND|MS_REC, NULL) = 0 > > + strace -f -e trace=mount,umount umount -l testmp2 > > umount("/root/3/testmp2", MNT_DETACH) = 0 > > + mountpoint testmp1/submount > > testmp1/submount is not a mountpoint > > Hmm, does this always happen this way, or is the MS_REC flag "sticky" > and causes the MNT_DETACH to be recursive? > > That looks a bit like a kernel misfeature, no?
To me it looks like the kernel is working as designed, but perhaps I am not getting what exactly are you asking. You can read all the details in about shared mounts and event propagation in Documentation/filesystems/sharedsubtree.txt. Use case described there is that if you clone (bind) a shared tree you need to make it a slave to shut down the propagation in the backward direction (it's bi-directional for shared trees by default). > > So now just imagine "testmp1/submount" was "/dev/pts". > > Hmm, so in nspawn we don't bind mount /dev/pts anymore, we instantiate a > new instance... /dev/pts was just an example, point was I would lose everything once my script started tearing down the chroot. Regards, Tvrtko _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
