mountall deadlocks with bind mounts below nfs mounts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mountall (Ubuntu) |
Fix Released
|
High
|
Unassigned |
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,
hg.build.
tmpfs /chroots/
/mnt/tools /chroots/
/ram-work /chroots/
/proc /chroots/
/proc /chroots/
/ram-hg /chroots/
/dev /chroots/
/dev /chroots/
/mnt/tools /chroots/
scratch:/chroots /chroots nfs ro,exec 0 0
/scratch /chroots/
/scratch /chroots/
tmpfs /chroots/
/ram-hg /chroots/
/ram-work /chroots/
scratch:/scratch /scratch nfs rw,exec,noatime 0 0
/chroots is nfs-mounted so comes up as a network filesystem.
/chroots/
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?
Changed in mountall (Ubuntu): | |
status: | New → Fix Committed |
importance: | Undecided → High |
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 /'nobootwait' flags depending on the order of mounts in
overridden; otherwise we will mis-tag various mounts and deadlock the
boot. Also fixes an inconsistency with the inheritance of
'bootwait'
/etc/fstab: we now always treat the 'nobootwait' flag as applying to
submounts. LP: #1223745, LP: #1153672.
-- Steve Langasek <email address hidden> Fri, 13 Sep 2013 22:23:55 -0700