Hi Al, all,
Please have a look at the command sequence below, does it look right to you?
+ 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("/dev/shm/testmp1", "/dev/shm/testmp2", 0x7fcd30b821e0, MS_MGC_VAL|
MS_BIND|MS_REC, NULL) = 0
+++ exited with 0 +++
+ strace -f -e trace=mount,umount umount -l testmp2
umount("/dev/shm/testmp2", MNT_DETACH) = 0
+++ exited with 0 +++
+ mountpoint testmp1/submount
testmp1/submount is not a mountpoint
+ echo nay
nay
+ umount testmp2
umount: testmp2: not mounted
+ umount testmp1
+ rmdir testmp1
+ rmdir testmp2
rmdir: failed to remove `testmp2': Device or resource busy
Previously unmounting the recursive bind target would not unmount the source,
which to me looks like a more sensible outcome.
However what could be causing this weird behaviour puzzles me since I am not
sure it is purely the kernel on it's own. When I first hit this problem some
months ago unfortunately I did not have the time to dig deeper. However a
mental note remained that I thought, at the time, it is possible some
userspace change was a contributing factor.
Regards,
Tvrtko
Hi,
On Thursday 28 March 2013 11:03:51 Ram Pai wrote:
> I tried these commands on a 3.8.0-rc1+ kernel and did not find the
> problem. Is this on a recent kernel?
I am on Fedora 17 latest, but I've seen this problem with different kernels.
Pretty sure from 3.5 something to 3.8 something. All Fedora flavoured. I will
try vanilla soon.
What I am not sure is whether this behaviour was there from the start (on
Fedora 17). I *think* it started to happen later on, which would mean a
potential userland change somehow causes it.
Would that be at all possible with some mechanism?
> > Previously unmounting the recursive bind target would not unmount the
> > source, which to me looks like a more sensible outcome.
>
> yes. it should not unless they are peer-mounts, which in your case is
> not.
What are these and how to create them?
Thanks,
Tvrtko
On Thursday 28 March 2013 13:05:56 Tvrtko Ursulin wrote:
> Hi,
>
> On Thursday 28 March 2013 11:03:51 Ram Pai wrote:
> > I tried these commands on a 3.8.0-rc1+ kernel and did not find the
> > problem. Is this on a recent kernel?
>
> I am on Fedora 17 latest, but I've seen this problem with different kernels.
> Pretty sure from 3.5 something to 3.8 something. All Fedora flavoured. I
> will try vanilla soon.
Just tried with vanilla 3.8.4 and it show exactly the same problem.
There must be something in userspace then which is able to configure the
"system" (which bit?) into some weird mode where this bug(?) starts to
trigger.
Regards,
Tvrtko
On Thursday 28 March 2013 23:35:49 Ram Pai wrote:
> On Thu, Mar 28, 2013 at 01:05:56PM +0000, Tvrtko Ursulin wrote:
> > Hi,
> >
> > On Thursday 28 March 2013 11:03:51 Ram Pai wrote:
> > > I tried these commands on a 3.8.0-rc1+ kernel and did not find the
> > > problem. Is this on a recent kernel?
> >
> > I am on Fedora 17 latest, but I've seen this problem with different
> > kernels. Pretty sure from 3.5 something to 3.8 something. All Fedora
> > flavoured. I will try vanilla soon.
> >
> > What I am not sure is whether this behaviour was there from the start (on
> > Fedora 17). I *think* it started to happen later on, which would mean a
> > potential userland change somehow causes it.
> >
> > Would that be at all possible with some mechanism?
> >
> > > > Previously unmounting the recursive bind target would not unmount the
> > > > source, which to me looks like a more sensible outcome.
> > >
> > > yes. it should not unless they are peer-mounts, which in your case is
> > > not.
> >
> > What are these and how to create them?
>
> These are mounts that are created by marking mount as shared, followed
> by bind mount, followed by submount and then unmount.
>
> Documentation/filesystem/sharedsubtree.txt has the details.
Knowing the right keywords certainly enabled me to hunt it down, thanks!
Culprit is systemd as per following commit:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
Regards,
Tvrtko