Comment 39 for bug 42121

This is the same issue as reported in Bug #211631. Reinhard Tartler says there that he may not have fully understood the problem, so his Fix Committed here may not be addressing the issue reported here.

See Mathias Gug's comments in Bug #211631:

"The issue discussed here boils down to the fact that network interfaces
can be brought down *before* network filesystems are unmounted thus
leading to a long timeout.

One option proposed was to move the umountnfs script earlier in the
shutdown sequence. Doing leads to the possibility that running processes
still have files opened on the network share. This is the reason why
S31umountnfs.sh is run *after* S20sendsigs. Some packages have their
shutdown scripts set too early in the boot sequence. These should be fix
them rather then moving the umountnfs script earlier in the shutdown
sequence.

Another option suggested was to use the ifdown.d infrastructure. That
means writing a script that is able to unmount network filesystems
according to the interface been brought down. However the script should
not unmount the remote filesystems when *a* network interface goes down
but rather unmount them when the *corresponding* network interface goes
down.

What *should* be happening in all cases is that the network route is
gone. Trying to send to it will return a no-route-to-host which can be
detected and handled by the kernel. So either the route isn't being torn
out when it should be, and we should fix that; or the cifs driver
doesn't handle no-route-to-host, and we should fix that. Adjusting the
timeouts or moving/adding init scripts shouldn't matter at all."

From my experience, a reliable *workaround* is to use Sander Marechal's umountcifs script (attached), and symlink as K15umountcifs (i.e. the key is that it is called prior to K16dhcdbd).

$ sudo ln -s /etc/init.d/umountcifs /etc/rc0.d/K15umountcifs
$ sudo ln -s /etc/init.d/umountcifs /etc/rc6.d/K15umountcifs