"killtime" parameter patch ?

Volker Lendecke Volker.Lendecke at SerNet.DE
Wed May 16 00:47:34 MDT 2012

On Tue, May 15, 2012 at 05:23:56PM -0700, Jeremy Allison wrote:
> Interesting situation just came up (original guilty party who
> raised the issue deleted :-).
> Testing a Samba server for reliability. Connected Windows client
> with open files.
> Ethernet cable gets unplugged for a few minutes, client IO fails,
> then it gets reconnected.
> Client reconnects to Samba, gets a new smbd but finds its open files
> still locked.
> "deadtime" doesn't fire because the smbd still has resources open.
> Original smbd is still hanging around so sharemode detection finds
> an open process.
> If the files are oplocked oplock break send will get a TCP reset
> and cause the original smbd to die, but what if the oplock was already
> broken ?
> In that case a "FILE_SHARE_NONE" blocks everything for as long as
> the original smbd is still around.
> Client has no way to signal original server smbd process that it
> should die.
> TCP timeouts will kill after 2 hours but this is considered *way*
> too long for client to wait. "reset on zero vc" isn't set due to
> potential NAT issues.
> So here is an (untested, but compiles and I think it'll do the job)
> solution. Parameter "killtime" (set in minutes). If nothing received
> on a TCP connection (including no SMBecho calls) for "killtime"
> minutes, it causes the smbd to commit suicide (even with open
> resources). Cleanly of course :-).
> Thoughts on whether this is a good idea ? If so I'll write up the
> man page :-).

No, I don't think this is a good idea. We have the keepalive
and deadtime parameters together with reset on zero vc. You
can also play with socket options, at least on Linux to
lower the dead connection detection:


might be a starting point.

The big question is -- how does Windows behave? afaik
Windows has the equivalent of "reset on zero vc" set always.

One idea for this particular case: What happens if we send a
netbios keepalive message from server to client when a
sharing violation is about to happen?


SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de

More information about the samba-technical mailing list