Comment 4 for bug 197346

Sebastien Bacher wrote:
> reassigning to network-manager but that's likely the wrong place too,
> describing how you do the mount and easy steps to trigger the hang would
> be a good idea most likely

Hi Sebastien,

Here's the steps (my comments are embedded in the output; I started
"tail -f /var/log/kern.log &" before this so you will see interleaved
kernel output):

$ sudo mount -vv /nas/muziek
parsing options: rw,credentials=/home/bsamwel/.smbpasswd,uid=1000,gid=1000

mount.cifs kernel mount options
unc=//nas\muziek,ip=*********,user=*******,pass=*******,ver=1,rw,credentials=/home/bsamwel/.smbpasswd,uid=1000,gid=1000

bsamwel@bakbeest:~$
[HERE I DISABLE NETWORKING THROUGH THE NETWORK MANAGER CONTEXT MENU]
Mar 8 23:13:02 bakbeest kernel: [ 905.225631] wlan0:
deauthenticate(reason=3)
Mar 8 23:13:02 bakbeest kernel: [ 905.292185] ADDRCONF(NETDEV_UP):
wlan0: link is not ready

$ time sudo umount -vv /nas/muziek
Trying to umount /nas/muziek
optind 2 unmount dir /nas/muziek
[THERE'S ABOUT A TEN SECOND TIME GAP HERE]
Mar 8 23:13:33 bakbeest kernel: [ 937.053478] CIFS VFS: server not
responding
Mar 8 23:13:33 bakbeest kernel: [ 937.053491] CIFS VFS: No response
for cmd 50 mid 11
umount2 succeeded
attempting to remove from mtab
1 matching entries in mount table
entry not copied (ie entry is removed)
done updating tmp file

real 0m47.908s
user 0m0.000s
sys 0m0.008s

Interestingly, during the umount I did a "route print" in another
terminal. It showed *no entries at all*. That means that any activity
from smbfs should get a "no route to host" immediately. I don't know if
waiting for a route to reappear is "by design" (because it might be). In
this case it does cause a delay of about 45-50 seconds per smbfs file
system at shutdown time -- and I have two such file systems, so my
hand-counted estimate of 90 seconds wasn't that bad. :-)

Cheers,
Bart