oplock_break: client failure in break - shutting down

[Bruce Tenison]

> 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?

> 
> I think you should try to brake that problem down to a situation as simple as 
> possible and provide some debug logs to the list so we can investigate on this. 
> Maybe in the end we will find that its client related but the knowledge about this 
> should be searchable in the archives.
Will work on it and see what I can get.  After mulling it over in my mind
last night, I came to the conclusion that we had a similar problem with
1.9.18pl10, but it wasn't as obvious a problem.

Thanks again for the help!

Bruce Tenison
btenison at dibbs.net

All the world's a stage, and we are merely players