[Bug 1153672] Re: mountall deadlocks with bind mounts below nfs mounts

Launchpad Bug Tracker 1153672 at bugs.launchpad.net
Sat Sep 14 16:09:05 UTC 2013


This bug was fixed in the package mountall - 2.51

---------------
mountall (2.51) unstable; urgency=low


  * Fix tagging of filesystems to not have local/remote inheritance
    overridden; otherwise we will mis-tag various mounts and deadlock the
    boot.  Also fixes an inconsistency with the inheritance of
    'bootwait'/'nobootwait' flags depending on the order of mounts in
    /etc/fstab: we now always treat the 'nobootwait' flag as applying to
    submounts. LP: #1223745, LP: #1153672.

 -- Steve Langasek <vorlon at debian.org>  Fri, 13 Sep 2013 22:23:55 -0700

** Changed in: mountall (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mountall in Ubuntu.
https://bugs.launchpad.net/bugs/1153672

Title:
  mountall deadlocks with bind mounts below nfs mounts

Status in “mountall” package in Ubuntu:
  Fix Released

Bug description:
  This is a bit speculative, as I need these VMs working again quickly
  so I'm bludgeoning around the issue rather than debugging it, but:

  # <file system> <mount point>   <type>  <options>       <dump>  <pass>
  proc	/proc	proc	nodev,noexec,nosuid	0	0
  # / was on /dev/sda1 during installation
  LABEL=root	/	ext4	errors=remount-ro	0	1
  /dev/fd0	/media/floppy0	auto	rw,user,noauto,exec,utf8	0	0
  hg.build.lal.cisco.com:/data/tools	/mnt/tools	nfs	ro,exec	0	0
  tmpfs	/chroots/squeeze/i386/tmp	tmpfs	size=100M	0	0
  /mnt/tools	/chroots/squeeze/x86_64/mnt/tools	auto	rbind	0	0
  /ram-work	/chroots/squeeze/x86_64/ram-work	auto	rbind	0	0
  /proc	/chroots/squeeze/i386/proc	auto	rbind	0	0
  /proc	/chroots/squeeze/x86_64/proc	auto	rbind	0	0
  /ram-hg	/chroots/squeeze/x86_64/ram-hg	auto	rbind	0	0
  /dev	/chroots/squeeze/i386/dev	auto	rbind	0	0
  /dev	/chroots/squeeze/x86_64/dev	auto	rbind	0	0
  /mnt/tools	/chroots/squeeze/i386/mnt/tools	auto	rbind	0	0
  scratch:/chroots	/chroots	nfs	ro,exec	0	0
  /scratch	/chroots/squeeze/x86_64/scratch	auto	rbind	0	0
  /scratch	/chroots/squeeze/i386/scratch	auto	rbind	0	0
  tmpfs	/chroots/squeeze/x86_64/tmp	tmpfs	size=100M	0	0
  /ram-hg	/chroots/squeeze/i386/ram-hg	auto	rbind	0	0
  /ram-work	/chroots/squeeze/i386/ram-work	auto	rbind	0	0
  scratch:/scratch	/scratch	nfs	rw,exec,noatime	0	0

  /chroots is nfs-mounted so comes up as a network filesystem.
  /chroots/squeeze/i386/proc and friends are considered to be local filesystems
  mountall sits around waiting for the bind mounts before it says local filesystems are finished
  The bind mounts can't be mounted without /chroots because their mount point doesn't exist
  upstart never brings up the network because it's waiting for the local filesystems

  Adding nobootwait to all the bind and tmpfs mounts makes it come up
  cleanly.

  I think the problem is that mount points below a network mount point
  need to be treated as network filesystems, not local ones.

  Has anybody ever mentioned that a fragile daemon to mount filesystems
  that blocks the entire boot process is a bad idea?

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




More information about the foundations-bugs mailing list