PR#21625: Smbd processes get stuck and consume 100% CPU.

Fredrik Ohrn ohrn at
Tue Aug 21 09:50:49 GMT 2001

On Mon, 20 Aug 2001 jeremy at wrote:

> I've jut checked some changes into HEAD and 2.2 CVS to address
> this problem. The first thing I did was to add a deliberate panic if
> an smbd is trying to break its own oplock and cannot find a reference
> to that file in its open file list. This will allow someone
> to use a debugger to catch this in the act (with an additional
> 'panic action' script).
> The second is a robustness fix that (theoretically) shouldn't
> be needed, that ensures that once an oplock break request
> has returned, that the record that caused this break to
> be triggered is removed by the requesting process (if it
> exists). The reason this shouldn't be neccessary is that
> the receiving process should be removing this record even
> if the client failed to respond to the break.
> If people experiencing the 'spin' problem could CVS update
> and test this change I'd appreciate it.


I've just tried the 2.2 CVS version and everything went bezerk.

It spews this message in the log for each and every file that is opened:

[2001/08/21 11:24:30, 0, pid=28021] smbd/open.c:open_mode_check(540)
  open_mode_check: cannot delete entry when breaking oplock (3) on file eudora/eudora.ini, dev = 80015e, inode = 9702566

And all Windows apps that try to lock files fail with the message that
the file is already locked by another application.

I guess del_share_entry always return -1...


   "It is easy to be blinded to the essential uselessness of computers by
   the sense of accomplishment you get from getting them to work at all."
                                                   - Douglas Adams

Fredrik Öhrn                               Chalmers University of Technology
ohrn at                                                  Sweden

More information about the samba-technical mailing list