[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