mountall deadlocks with bind mounts below nfs mounts

Bug #1153672 reported by Andrew Suffield
6
This bug affects 1 person
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,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?

Steve Langasek (vorlon)
Changed in mountall (Ubuntu):
status: New → Fix Committed
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

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 <email address hidden> Fri, 13 Sep 2013 22:23:55 -0700

Changed in mountall (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.