Stale smbd processes (was: DOS: Clients can freeze other clients smbd)
Nicolas.Williams at wdr.com
Thu Sep 2 16:20:10 GMT 1999
I've posted about this once before.
Basically, NT SMB clients are very aggressive in reconnecting to SMB
servers in the face of network timeouts all the while smbd may fail to
notice that the TCP socket in question is dead.
This shouldn't happen as TCP should recover from any loss of FIN or
FIN/ACK packets. However I remember a Solaris bug where Solaris would
respond with two packets (ACK, then FIN/ACK) to FIN packets that have
more than 0 bytes of data; though this is technically legal behaviour,
some stacks respond by resending the FIN + data packet (as opposed to
just a FIN), thus entering an infinite retransmission loop and the
socket never closes.
Meantime, the NT clients that reconnect cause a new smbd process to be
spawned for them. When the reconnecting client attempts to obtain locks
it already had, smbd blocks while waiting for the stale smbd to give up
the locks in question, and since the stale smbd is waiting for the
client (which considers the connection closed) to respond to oplock
break requests (or what have you) you get a DEADLOCK.
There's two ways around this problem:
- set the 'keepalive' parameter to a sufficiently small value
- run a script via 'root preexec' and 'root postexec' to check for and
kill smbd process[es] that were serving the same client.
I use both approaches (they are not mutually exclusive).
My analysis of the problem may not be correct or very accurate and I'm
writing from memory here, but the solution works fine for me.
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
More information about the samba-technical