smbfs umount hangs during shutdown because NetworkManager network connection is gone

Bug #197346 reported by Bart Samwel
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

When I do an fstab smbfs mount through a network interface which is managed by NetworkManager, and then shutdown, the network connection is gone immediately, and then during shutdown the unmounting of the smbfs file system hangs for 90 seconds because it doesn't get a response from the server. I'd expect this to be a simple "no route to host" case, which should cause an immediate error, not a network timeout. In any case, 90 seconds of unresponsiveness is so long that I used to do a hard power down because I thought the shutdown process was hanging. So, please get rid of this timeout!

Release: Hardy alpha up-to-date as of March 1, 2008.

description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. What version of Ubuntu do you use? Why did you open the bug against nautilus, that's not likely the software doing the unmounting there

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Bart Samwel (bart-samwel) wrote :

Hmm, I didn't actually report it to nautilus, that change was made by Dereck Wonnacott. I was already wondering about that, but I thought that it might be some Ubuntu-internal distribution of responsibility thing. :-)

Anyway, I run Hardy alpha, following daily updates. I don't know if earlier Ubuntu versions have the same problem, I've just started using these smb mounts recently.

Revision history for this message
Sebastien Bacher (seb128) 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

Changed in nautilus:
assignee: desktop-bugs → nobody
status: Incomplete → New
Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 197346] Re: smbfs umount hangs during shutdown because NetworkManager network connection is gone

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

Revision history for this message
jamesryanhorn (ryan-thehornfamily) wrote :

I get the same hang when trying to unmount my network SMB shares. I do NOT use Network Manager and instead use WICD. So it appears not to be a NM issue.

My fstab entry for my share:

//server/shared_data /media/shared_data smbfs username=xxxxx,password=xxxxx,file_mode=0777,dir_mode=0777 0 0

Not really sure what else to post.

Revision history for this message
jamesryanhorn (ryan-thehornfamily) wrote :

Forgot to say, I am running the latest 8.04 Hardy.

Revision history for this message
MichaelE (michael-eitelwein) wrote :

Hi

got the same problem on a laptop (8.04 upgrade from 7.10, 32bit) with WLAN and CIFS shares. I found another bug report Bug #184676 and think it is the same problem?

There is a workaround by changing the order of the rc-scripts --> umount before closing the network connections.

Revision history for this message
Bart Samwel (bart-samwel) wrote :

MichaelE wrote:
> Hi
>
> got the same problem on a laptop (8.04 upgrade from 7.10, 32bit) with
> WLAN and CIFS shares. I found another bug report Bug #184676 and think
> it is the same problem?
>
> There is a workaround by changing the order of the rc-scripts --> umount
> before closing the network connections.

But I think NetworkManager already loses the connection at logout time,
right?

--Bart

Revision history for this message
MichaelE (michael-eitelwein) wrote :

Hm, at least not with my laptops. Connection stays open even after logout. But do not know whether there is a setting to steer this behaviour.

Revision history for this message
Bart Samwel (bart-samwel) wrote :

MichaelE wrote:
> Hm, at least not with my laptops. Connection stays open even after
> logout. But do not know whether there is a setting to steer this
> behaviour.

Even if it does, what if somebody turned off the wireless network
switch, pulled the network cable plug, ...? Then you're still going to
see needless timeouts.

--Bart

Changed in network-manager:
status: New → Confirmed
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.