kernel-packages team mailing list archive

[Serge Hallyn <1402834@xxxxxxxxxxxxxxxxxx>]

Quoting Andy Whitcroft (apw@xxxxxxxxxxxxx):
> The big question is whether we tried to unmount the mount to trigger the
> exit.

Manually reproducing these steps doesn't seem to reproduce it:

sshfs -f -d -o allow_other somehost:$HOME /tmp/d
lxc-unshare -s MOUNT -- /bin/bash
	mount --bind /tmp/d /mnt
	umount /mnt
	umount /tmp/d
	exit
# sshfs is still running

> If we just killed the fuse server then the kernel behaviour seems
> valid.

The fuse server is running on the host, not in the container.  We do
not kill the fuse server.  It seems as though somehow sees some event
which makes it think it should exit.

> If we attempted to unmount it, that let the server go, then the
> umount failed, that sounds wrong.

We don't do anything to let the mount on the server go.  Userspace
in the container does what it does on shutdown (sync;sync;umount
or whatever)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1402834

Title:
  fuse filesystems get disconnected on container exit

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  When bind-mounting a directory from a fuse filesytems into a container,
  then when the container is shut down, the userspace process serving the
  fuse fs is terminated.  The original fuse mountpoint remains busy until it
  is manually unmounted.

  I've tested this with sshfs, git://github.com/stgraber/cgmanagerfs,
  the bbfs example fs from http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/,
  or git://github.com/lxc/lxcfs.

  To reproduce:

  Mount a fusefs - say sshfs - with -o allow_other, let's say onto
  /tmp/d.

  sshfs -f -d -o allow_other somehost:$HOME /tmp/d

  Bind that into a container by adding

  lxc.mount.entry = /tmp/d freezer none bind,create=dir 0 0

  to the container's config.

  start the container, stop it.

  the fuse program stops (exits 0 in fact)

  the mount is not cleaned up - ls /tmp/d on the host henceforth
  complains:

  	ls: cannot access /tmp/d Transport endpoint is not connected"
  	
  (sudo umount /tmp/d cleans it up)

  I don't know for sure whether this is a kernel or libfuse bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402834/+subscriptions