The attached patch for 2.1.66 smbfs and 1.9.17p1 smbclient should take
care of at least some of the problems with reconnecting to a server.
OK...
[me:3] caffeine:~$ cat /proc/mounts|grep smbfs;echo;netstat|grep ssn
<NULL> /mounts/helpdesk smbfs rw 0 0
tcp 0 0 192.168.0.2:1025 server1.ix.:netbios-ssn CLOSE
-- So it's mounted the the NT box has closed the connection...
[me:3] caffeine:~$ ls -l /mounts/helpdesk
smb_trans2_request: result=-32, setting invalid
smb_retry: timed out, try again later
smb_proc_readdir_long: error=-32, breaking
smb_refill_dircache: readdir failed, result=-32
total 0
-- and again...
[me:3] caffeine:~$ ls -l /mounts/helpdesk
smb_retry: timed out, try again later
smb_proc_readdir_long: error=-5, breaking
smb_refill_dircache: readdir failed, result=-5
total 0
-- smbclient doesn't get any signals here...
-- as root on another vt --
[root:1] caffeine:~# kill -USR1 249
[root:1] caffeine:~# smb_newconn: server not locked, count=1
smb_offerconn: server not locked, count=1
smb_offerconn: state valid, pid=249
-- then...
[me:3] caffeine:~$ ls -l /mounts/helpdesk
total 78447
[...]
and it works as expected....
So things seems to be much more robust than before - but it still doesn't
recognize the closed sockets properly.
Perhaps a threshold setting so that n consecutive timeouts within x jiffies
means we reconnect?
I'm not sure what this will do to open files though... (or indeed if there
are file open as to whether the connection will be closed in the first
place).
In theory... the remote end could reboot. Any access to open files should
probably return EIO or something similar. (This probably also means checking
upon close(2) if a file was R/W and returning and error here).
-Chris