oplock_break: client failure in break - shutting down

[Robert Dahlem]

Bruce,

On Mon, 21 Dec 1998 02:42:48 +1100, Bruce Tenison wrote:

>> You should be aware of the fact that indeed there is a problem with your 
>> configuration (oplocks should be brakeable easily) and that running without 
>> oplocks may have serious negative performance impacts.

>Well, it seems that many (if not all) of our 95/98 clients are having the
>problem of not succeeding with the break request.  For example, my machine
>(tenison) requests:
>[1998/12/18 10:36:21, 0] smbd/oplock.c:request_oplock_break(935)
>  request_oplock_break: no response received to oplock break request to 
>pid 14904 on
>port 1243 for dev = 301, inode = 620605
>
>and obviously gets no response. So I go searching in the logs for this pid
>and inode number and get in the logs for another machine (ahooks):
>[1998/12/18 10:36:29, 0] smbd/oplock.c:oplock_break(734)
>  oplock_break: receive_smb timed out after 30 seconds.
>  oplock_break failed for file COMM.INF (dev = 301, inode = 620605).
>[1998/12/18 10:36:29, 0] smbd/oplock.c:oplock_break(804)
>  oplock_break: client failure in break - shutting down this smbd.
>[1998/12/18 10:36:29, 1] smbd/service.c:close_cnum(510)
>  ahooks (0.0.0.0) closed connection to service virus

>This seems to be the standard routine for no matter which machine has the
>oplock, and whether or not the machine is a 95, 95b, 95SR1, or 98 client
>as far as I can tell.

>I've tried to up the log level on the pid that has the lock, but I never
>know which it will be (since it shuts down and closes the connection), so
>I guess we'll have to up the log level on all smbd processes until we get
>a good snapshot???  Any suggestions as to the log level to put smbd?

Try the following in smb.conf: In your global section add the line

	include = /some_path/smb.conf.%I

Now lets assume then IP address of your machine were 192.168.1.1

Then create a file /some_path/smb.conf.192.168.1.1 with the following content:

	
	debug level = 10
	log file = /some_path/log.%I

Restart the smbd for that machine (just parse the output of smbstatus for your IP 
address, kill the associated process ID and do a "DIR X:" from the command line 
with X: is some drive letter of a mounted share). Now you should have a growing 
log file with debug level 10 just for your machine.

Start

	tcpdump host <server_IP> and host <client_IP>

and work until the error comes back. Be nice and use a patched tcpdump with the 
SMB extensions (you can get this from one of the samba mirror sites) but its not 
essential in the first step.

>I came to the conclusion that we had a similar problem with 1.9.18pl10, but it 
>wasn't as obvious a problem.

Check it with the 2.0 beta code: This will be the one further development goes to.

Hasta la vista,
               Robert

-- 
---------------------------------------------------------------
Robert.Dahlem at frankfurt.netsurf.de
Radio Bornheim - 2:2461/332 at fidonet +49-69-4930830  (ZyX, V34)
                 2:2461/326 at fidonet +49-69-94414444 (ISDN X.75)
---------------------------------------------------------------