Comment 52 for 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.