[Bug 988394] Re: Reboot hangs because /etc/rc6.d/S40umountfs chokes on non-existent mounts

[Steve Langasek]

I don't think this analysis is correct.  At the time the umountfs script
finishes, *all* filesystems are supposed to be unmounted.  This includes
any mount points watched by autofs.  So why is autofs still running at
this point in the shutdown?  The autofs daemon should be shut down
*prior* to /etc/rc6.d/S35networking, since at that point there's no
network left and autofs should no longer be trying to mount new
filesystems anyway!

And if I look at the autofs5 package, it has a wrong upstart job that
does 'stop on runlevel [!2345]', which does not properly serialize the
shutdown to ensure the service is stopped before we reach the unmounting
phase.  Thus there's a race between /etc/init/rc.conf and
/etc/init/autofs.conf.

Reassigning to the autofs5 package.

** Package changed: sysvinit (Ubuntu) => autofs5 (Ubuntu)

** Changed in: autofs5 (Ubuntu)
   Importance: Undecided => High

** Changed in: autofs5 (Ubuntu)
     Assignee: Canonical Foundations Team (canonical-foundations) => Canonical Server Team (canonical-server)

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

Title:
  Reboot hangs because /etc/rc6.d/S40umountfs chokes on non-existent
  mounts

Status in “autofs5” package in Ubuntu:
  New

Bug description:
  All our machnes were hanging indefinitely when asked to reboot.  We
  traced it down to the /etc/rc6.d/S40umountfs script hanging.  The
  problem in our case is that autofs leaves phantom entries in
  /proc/mounts after it's stopped (I'm reporting this as a separate bug
  #988397).  The entries autofs creates are not real mount points -
  these are the directories monitored by the autofs daemon, which mounts
  file systems as subdirectories to those directories.

  The expected behaviour for the umountfs script would be to skip over
  any bogus mount points, left over by autofs or anything else.

  For instance, we found out that by the time /etc/rc6.d/S40umountfs
  runs the autofs daemon is stopped (as expected) and all directories
  that had been mounted by it are already unmounted (as expected, it
  mounts NFS shares in our case, which are unmounted by
  /etc/rc6.d/S31umountnfs.sh).  However, /proc/mounts still contained
  the following lines:

  /etc/auto.nfs_h /h autofs rw,relatime,fd=6,pgrp=1004,timeout=300,minproto=5,maxproto=5,indirect 0 0
  /etc/auto.nfs_s /s autofs rw,relatime,fd=12,pgrp=1004,timeout=300,minproto=5,maxproto=5,indirect 0 0
  /etc/auto.nfs_cdf /cdf autofs rw,relatime,fd=18,pgrp=1004,timeout=300,minproto=5,maxproto=5,direct 0 0

  which confused the umountfs script.  The variable REG_MTPTS, among the
  proper file systems, contained the following: "/h /s /cdf".
  Subsequently, when the umountfs script invoked "fstab-decode umount
  ..." it hung trying to unmount these non-existent file systems.

  In summary, I think that either the umountfs script should be made
  smarter to not pass bogus mount points to fstab-decode, or fstab-
  decode should be more robust and not hang when given a mount point
  that does not exist.  Perhaps both.

  Thanks!

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: initscripts 2.88dsf-13.10ubuntu11
  ProcVersionSignature: Ubuntu 3.2.0-23.36-generic-pae 3.2.14
  Uname: Linux 3.2.0-23-generic-pae i686
  ApportVersion: 2.0.1-0ubuntu6
  Architecture: i386
  Date: Wed Apr 25 11:33:07 2012
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   SHELL=/local/bin/bash
  SourcePackage: sysvinit
  UpgradeStatus: No upgrade log present (probably fresh install)

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