request_oplock_break - a clue - what does it mean ?

[Gregory Hosler]

Hi all,

I increased the log level, and found something very interesting out.
I know now what causes a sbmd to go into infinite hibernation on
Solaris. I do not know why, it is probably something Solaris specific,
I thought that a "dont descend" would have resolved my problem, but
it has not. details at the end.

Scenerio:

  solaris 2.5.1 running samba 2.0.0 (happens w/ several if not all
                if the 1.19 releases as well, it is not samba specific).

  NT 4 sp 3

On samba, create a [root] entry that looks like:

[root]
   comment = Root Dir
   path = /
   dont descend = /dev

On NT, map the root directory to a network drive. open up [my computer]
and click on the network drive. In the process of displaying the icons
for the directory (/), NT will look for "desktop.ini" in each directory.
When it gets to /net, the particular smbs that is stat'ing /net/desktop.ini
will hang. (this is easily reproduceable in an xterm, just "ls /net/foo"
and your ls will hang. I have no idea what /net is. it _looks_ like a
regular directory, there is nothing in fstab to indicate that it is a mount
point. very peculiar.)

anyway, NT will hang waiting for teh smbd response, and will eventually
timeout and give up. it takes a very long time. more than a minute. maybe
2.

Next close the root directory window and reclick on the root network
drive. (alternately, click view->refresh on the root window - you need
to cause a refresh). NT will request alot of file information, but because
the 1st smbd is now "hung", another sbmd will be started (presumably to
handle the "load"). When the new smbd gets to the same file (i.e.
/net/desktop.ini), this process too will hang.

suffice it to say that any access to /net will cause the smbd to go zombie.
I'll check w/ my solaris support tomorrow to learn why this is.

Note that the very 1st smbs to go after /net/desktop.ini has registered
an oplock, and because teh stat hangs the process, and never returns, the
oplock is never released. Hence all future sbmds will report a

        request_oplock_break: no response received to oplock break request
        to pid (the pid of the 1st smbd)

I would have thought that the solution would be to add /net to the list of
"dont descend", so I did. That didn't work so I added "net", that still
didn't work so I added "./net". still no luck.

My don't descent now looks like:

[root]
   comment = Root Dir
   path = /
   dont descend = proc,dev,net,/proc,/dev,/net,./proc,./dev,./net

and verified in my log file:

[1999/01/17 14:30:26, 8] smbd/trans2.c:(752)
  dirpath=<./> dontdescend=<proc,dev,net,/proc,/dev,/net,./proc,./dev,./net>

but it appears that NT is specify a full file path without checking the
directory, and samba descends into the directory. Is this intentional?

Or is there some other way to prevent a descent into a directory
contained within a specified full path ?

regards,

-Greg

----------------------------------
E-Mail: Gregory Hosler <gregory.hosler at eno.ericsson.se>
Date: 17-Jan-99
Time: 13:37:419

"And where were you at 00:00:00 GMT, January 1, 1970?"

-- 
As far as the laws of mathematics refer to reality, they are not
certain, and as far as they are certain, they do not refer to reality.
                -- Albert Einstein
----------------------------------