PR#21625: Smbd processes get stuck and consume 100% CPU.
ohrn at chl.chalmers.se
Tue Aug 21 09:50:49 GMT 2001
On Mon, 20 Aug 2001 jeremy at valinux.com 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 chl.chalmers.se Sweden
More information about the samba-technical