Re: 2.1.66 smbfs oops

Bill Hawes (whawes@star.net)
Thu, 27 Nov 1997 19:44:37 -0500


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