Alternate approaches to lock/dead-client problem.
Nicolas Williams
Nicolas.Williams at wdr.com
Tue Jan 26 17:25:58 GMT 1999
On Tue, Jan 26, 1999 at 10:39:49AM -0500, David Collier-Brown wrote:
> I'd like to suggest looking at the locking/oplocking behavior
> instead of directly killing the smbd: if a lock is held on a
> file X by a client Y, and another lock is requested, then
> we may want to check that the lock's holder (Y') is still alive.
> If this were just an oplock, the probable behavior would be
> for the server to send a "break" request to the client, the
> client be fond to be dead and the server to clean up...
Yeah, but then there's deny modes.
> Arguably, any other lock request from the same client should
> trigger a similar check for the death of the "first" client.
This would be a good thing to do. My workaround is a very crude
implementation of what you suggest. I'd love to see a source level fix
however.
> As a non-expert, this raises two questions in my mind
> 1) is there room to store client IDs in the locks structure?
> I see a flock64 used as SMB_STRUCT_FLOCK, which had a
> pid, which will tell us the nmbd to ask, but I don't see
> an obvious and inexpensive way to ask "which client"
Dunno. Haven't checked (I'm not a Samba developer :) but I suppose that
Samba can be modified to keep track of connected clients in a similar
way to how it keeps track of locks held by clients.
Thus, if a new smbd process has a client connected for which there is
another smbd then the new smbd could send a signal to the old smbd which
would prompt the old smbd to check that the client is still alive and,
if not, then die.
But the question is: is it correct to assume that an SMB session over
TCP is abandoned when a new connection with the same parameters is
opened to the server?
That's my assumption. And if safe then there's no need to implement a
check for abandoned connections; if they're logically abandoned, then
drop them. The worst thing that could happen is that you're dropping a
valid connection, prompting the client to reconnect. But then, if the
old connection is just dropped with no checks that might open up a
connection-hijacking hack.
*shrug*
A word from Samba team members about this issue could help ;|
> 2) could one reorder the locking logic so that the oplock
> test comes first, which would presumably detect a dead
> client at low cost...
This, I believe, depends on the NT client. Unfortunately. I hope I'm wrong.
> --dave (trying to think of a third question) c-b
> --
> David Collier-Brown, | Always do right. This will gratify some people
> 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
> Willowdale, Ontario | http://java.science.yorku.ca/~davecb
> Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com
Nico
More information about the samba-technical
mailing list