smbmounts hang around after windows client disconnects

[Urban Widmark]

On Thu, 29 Nov 2001, Joel Hammer wrote:

> Using 2.2.1a and a 2.4 kernel patched for win4lin. 

Which 2.4.x? Later versions (x > 13?) does not try to disconnect cleanly
and should work better at shutdown.

> If a windows client shuts down while the linux box is still connected, the
> share is not removed from my mount list or from /proc/mounts

It is probbaly waiting for the server end to reply to it's disconnect
message. Later versions have temporarily lost the capability to send
disconnect messages.


> It cannot be removed with umount. I can kill the smbmount with kill -15 but
> the share is still there with mount.
> Telinit to 1 does not remove the share.
> Attempts to access the share after the windows client shuts down results in
> the process hanging. 

If you wait long enough I think tcp will timeout (take a shower, eat
breakfast - that sort of wait), at least that is what it does for me. When
shutting down perhaps you can't see that, or maybe there are additional
retries.

Killing smbmount is never a good idea. That is not where it is waiting
(not for too long anyway).


The problem of smbfs blocking when the other end disappears is known. It's
a bug in the smbfs socket code where it (basiclly) assumes it will receive
a reply if it sends a request.

It does timeout, but it takes far too long. I'm working on a better
version.

/Urban