Using Samba 1.9.18p10 on RH5.2 Linux. I've noticed that when a mapped drive is left idle for awhile (OS/2 Warp 4 or NT4WS client) that an operation on that share (eg. a directory listing) will take several seconds to complete. After that, operations will again be responsive until the share is once again left idle for a long period. I'm not sure how long it takes to become slow again. This looks like something at either the client or server is disconnecting after an extended idle time but retaining the authentication info, so that one must once again suffer the initial connection time. What am I seeing, and is there any way to fix it? Ken mailto:shiva@well.com http://www.well.com/user/shiva/ http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)
On Thu, 25 Feb 1999 10:04:13 +0100 (CET), Robert Dahlem wrote:>On Thu, 25 Feb 1999 14:52:07 +1100, Kenneth Porter wrote: > >>I've noticed that when a mapped drive is left idle for awhile (OS/2 >>Warp 4 or NT4WS client) that an operation on that share (eg. a >>directory listing) will take several seconds to complete. After that, >>operations will again be responsive until the share is once again left >>idle for a long period. I'm not sure how long it takes to become slow >>again. > >This looks like you have set up "dead time" in smb.conf with something not >equalling zero. Samba disconncts the client after "dead time" minutes from the >share (only when no files are open on the share) and the client later has to >reconnect.Just checked, and deadtime (as documented in "man smb.conf") isn't in there. According to the man page, it defaults to zero (ie. no deadtime checking). Could smbd have been compiled with some non-zero default? How would I determine this? (debug level?) Meanwhile, I'll try explicitly setting it to zero. Ken mailto:shiva@well.com http://www.well.com/user/shiva/ http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)
Kennth, On Thu, 25 Feb 1999 14:52:07 +1100, Kenneth Porter wrote:>I've noticed that when a mapped drive is left idle for awhile (OS/2 >Warp 4 or NT4WS client) that an operation on that share (eg. a >directory listing) will take several seconds to complete. After that, >operations will again be responsive until the share is once again left >idle for a long period. I'm not sure how long it takes to become slow >again.This looks like you have set up "dead time" in smb.conf with something not equalling zero. Samba disconncts the client after "dead time" minutes from the share (only when no files are open on the share) and the client later has to reconnect. Hasta la vista, Robert -- --------------------------------------------------------------- Robert.Dahlem@gmx.net Radio Bornheim - 2:2461/332@fidonet +49-69-4930830 (ZyX, V34) 2:2461/326@fidonet +49-69-94414444 (ISDN X.75) ---------------------------------------------------------------
On Fri, 26 Feb 1999 00:07:44 +0100 (CET), Robert Dahlem wrote:>On Thu, 25 Feb 1999 21:51:35 +1100, Kenneth Porter wrote: > >>>>I've noticed that when a mapped drive is left idle for awhile (OS/2 >>>>Warp 4 or NT4WS client) that an operation on that share (eg. a >>>>directory listing) will take several seconds to complete. After that, >>>>operations will again be responsive until the share is once again left >>>>idle for a long period. I'm not sure how long it takes to become slow >>>>again. >>> >>>This looks like you have set up "dead time" in smb.conf with something not >>>equalling zero. Samba disconncts the client after "dead time" minutes from the >>>share (only when no files are open on the share) and the client later has to >>>reconnect. >> >>Just checked, and deadtime (as documented in "man smb.conf") isn't in >>there. According to the man page, it defaults to zero (ie. no deadtime >>checking). Could smbd have been compiled with some non-zero default? >>How would I determine this? > >Run testparm, it will tell you. > >Just to go somewhat further into details: Can you try to run smbstatus before >doing the first operation you expect to respond slowly? Do you see your share >being connected? Afterwards?If I remove the deadtime setting from smb.conf, testparm claims it's zero. Now that I've set the deadtime to zero, it looks like the problem has gone away. I poked around in the source RPM (RH5.2 distribution), and it looks like the default is zero, so I'm at a loss to explain the observed behavior. Is it possible that it's related to a non-zero user level or password level? I originally had these set to handle some mixed-cased names and passwords, before going to encrypted passwords. I turned on encryption support and this solved a lot of my NT access problems, but I didn't immediately remove the user/password level options. At the same time I set deadtime to zero, I commented out the level params, so perhaps that's what speeded things up. What's puzzling is why they should be relevant if encrypted passwords are in use. Ken mailto:shiva@well.com http://www.well.com/user/shiva/ http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)