linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Mount propagation issue
@ 2014-09-26 23:31 Ross Lagerwall
  2014-09-29 23:30 ` Eric W. Biederman
  0 siblings, 1 reply; 3+ messages in thread
From: Ross Lagerwall @ 2014-09-26 23:31 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-fsdevel

Hi,

I have encountered a strange bug (on 3.14, 3.16.3 and master) regarding
mount namespaces and a particular directory.  Somehow, mounts are being
mounted successfully but disappearing when the process dies, but only
for /mnt/puppy, not for any other directory in the system:

# grep puppy /proc/mounts            # nothing mounted yet
# mount -t tmpfs tmpfs /mnt/puppy
# grep puppy /proc/mounts            # no output

# mount -t tmpfs tmpfs /mnt/puppy2
# grep puppy /proc/mounts
tmpfs /mnt/puppy2 tmpfs rw,relatime 0 0

Furthermore, I wrote a program to mount /mnt/puppy and immediately
read /proc/mounts:
# grep puppy /proc/mounts            # no output
# ./mounter
tmpfs /mnt/puppy tmpfs rw,relatime 0 0
# grep puppy /proc/mounts            # no output

Finally, I note that the problem seems to occur if the mount needs to be
propagated to the default namespace (note that systemd causes namespaces
to be shared by default):
# unshare -m

subshell # mount -t tmpfs tmpfs /mnt/puppy
subshell # grep puppy /proc/mounts   # no output
subshell # mount --make-rprivate /
subshell # mount -t tmpfs tmpfs /mnt/puppy
subshell # grep puppy /proc/mounts   # success!
tmpfs /mnt/puppy tmpfs rw,relatime 0 0
subshell # umount /mnt/puppy
subshell # exit

# mount --make-rprivate /            # back in the default namespace
# mount -t tmpfs tmpfs /mnt/puppy
# grep puppy /proc/mounts            # no output

I hope someone has an idea of what's going on or how to debug this
because I've run out of ideas...

Thanks!
-- 
Ross Lagerwall

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Mount propagation issue
  2014-09-26 23:31 Mount propagation issue Ross Lagerwall
@ 2014-09-29 23:30 ` Eric W. Biederman
  2014-09-30 17:46   ` Ross Lagerwall
  0 siblings, 1 reply; 3+ messages in thread
From: Eric W. Biederman @ 2014-09-29 23:30 UTC (permalink / raw)
  To: Ross Lagerwall; +Cc: linux-kernel, linux-fsdevel

Ross Lagerwall <rosslagerwall@gmail.com> writes:

> Hi,
>
> I have encountered a strange bug (on 3.14, 3.16.3 and master) regarding
> mount namespaces and a particular directory.  Somehow, mounts are being
> mounted successfully but disappearing when the process dies, but only
> for /mnt/puppy, not for any other directory in the system:
>
> # grep puppy /proc/mounts            # nothing mounted yet
> # mount -t tmpfs tmpfs /mnt/puppy
> # grep puppy /proc/mounts            # no output
>
> # mount -t tmpfs tmpfs /mnt/puppy2
> # grep puppy /proc/mounts
> tmpfs /mnt/puppy2 tmpfs rw,relatime 0 0
>
> Furthermore, I wrote a program to mount /mnt/puppy and immediately
> read /proc/mounts:
> # grep puppy /proc/mounts            # no output
> # ./mounter
> tmpfs /mnt/puppy tmpfs rw,relatime 0 0
> # grep puppy /proc/mounts            # no output
>
> Finally, I note that the problem seems to occur if the mount needs to be
> propagated to the default namespace (note that systemd causes namespaces
> to be shared by default):
> # unshare -m
>
> subshell # mount -t tmpfs tmpfs /mnt/puppy
> subshell # grep puppy /proc/mounts   # no output
> subshell # mount --make-rprivate /
> subshell # mount -t tmpfs tmpfs /mnt/puppy
> subshell # grep puppy /proc/mounts   # success!
> tmpfs /mnt/puppy tmpfs rw,relatime 0 0
> subshell # umount /mnt/puppy
> subshell # exit
>
> # mount --make-rprivate /            # back in the default namespace
> # mount -t tmpfs tmpfs /mnt/puppy
> # grep puppy /proc/mounts            # no output
>
> I hope someone has an idea of what's going on or how to debug this
> because I've run out of ideas...

My guess is that some process (systemd?) is configured to unmount that
directory if anything shows up mounted on it.  So when the mount
propogates it gets unmounted and then the unmount propogates as well.

Eric


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Mount propagation issue
  2014-09-29 23:30 ` Eric W. Biederman
@ 2014-09-30 17:46   ` Ross Lagerwall
  0 siblings, 0 replies; 3+ messages in thread
From: Ross Lagerwall @ 2014-09-30 17:46 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-kernel, linux-fsdevel

On Mon, Sep 29, 2014 at 04:30:31PM -0700, Eric W. Biederman wrote:
> Ross Lagerwall <rosslagerwall@gmail.com> writes:
> > I hope someone has an idea of what's going on or how to debug this
> > because I've run out of ideas...
> 
> My guess is that some process (systemd?) is configured to unmount that
> directory if anything shows up mounted on it.  So when the mount
> propogates it gets unmounted and then the unmount propogates as well.
> 

Ah yes!  I'd forgotten that I previously had experimented with a mount
unit file for that directory and didn't realize that systemd would
actively prevent anything from being mounted at that point even if the
mount unit was inactive.

Turning up systemd's log level showed the following:
Sep 30 06:59:28 hobo systemd[279]: mnt-puppy.mount changed dead -> mounted
Sep 30 06:59:28 hobo systemd[1]: mnt-puppy.mount changed dead -> mounted
Sep 30 06:59:28 hobo systemd[1]: Unit mnt-puppy.mount is bound to inactive service. Stopping, too.
Sep 30 06:59:28 hobo systemd[1]: Trying to enqueue job mnt-puppy.mount/stop/fail
Sep 30 06:59:28 hobo systemd[1]: Installed new job mnt-puppy.mount/stop as 240
Sep 30 06:59:28 hobo systemd[1]: Enqueued job mnt-puppy.mount/stop as 240
Sep 30 06:59:28 hobo systemd[1]: Unmounting /mnt/puppy...
Sep 30 06:59:28 hobo systemd[1]: About to execute: /bin/umount -n /mnt/puppy

Thanks for pointing me in the right direction!
-- 
Ross Lagerwall

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-09-30 17:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-26 23:31 Mount propagation issue Ross Lagerwall
2014-09-29 23:30 ` Eric W. Biederman
2014-09-30 17:46   ` Ross Lagerwall

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).