Messages in this thread | | | Date | Thu, 27 Nov 1997 19:44:37 -0500 | From | Bill Hawes <> | Subject | Re: 2.1.66 smbfs oops |
| |
Chris Wedgwood wrote: > OK. Left things going over night. I left strace going too... and at some > point the smbclient processes did leeave pause and attempt to reconnect. > (Probably wehn updatedb ran via the cron). > > These would correspond to that: > > 07:43:09 caffeine kernel: smb_offerconn: state valid, pid=2964 > 07:43:09 caffeine kernel: smb_retry: new connection pid=2964 > 07:43:09 caffeine kernel: smb_proc_readdir_long: error=-5, retrying > > When deliberatly try to access the volumes though... no luck. No signals > sent to the smbclient processes, etc.
Hi Chris,
I've tracked down and fixed some of the problems in smbclient, and will post a patch tomorrow. Smbfs now recovers from making an NT share unshared.
The problem was twofold -- smbfs needed to recognize a fatal server error sooner and invalidate the connection, and then the smbclient process was terminating if it got an error while trying to reopen the socket. I don't know whether these changes will fix all of the lost connection problems, but it should be a good start.
> P.S. Why has the connection stuff been moved into user space? Its seems a > tad unreliable having to keep a user-space program around just to > access volumes, which may be an very infrequent times. > > Things like shutdown scripts can also interfere here surely... > (likewise with killall5)
Maintaining connections with SMB servers is somewhat complicated, and since Samba already does that pretty well it makes sense to leverage the code. I think we can make it work reliably once a few more bugs are tracked down.
Regards, Bill
| |