I hope someone can enlighten me on this. Situation: NT network, Samba PDC, about 20 NT 4.0 workstations. log(s).smbd are created per machine for easier analysis (as log.smbd.<NetBios Name>). Not often, but often enough to be of concern, are errors in request_oplock_break that seem to indicate that another smbd process that should be listening for break requests on a UDP socket isn't, or isn't responding. Some time ago, for some very strange reason, the system was configured with share modes off, which caused these errors to occur constantly. That was corrected and now they are infrequent, but not infrequent enough, I suspect, to ignore. One possibly significant fact: there are two subnets. The cross-subnet browsing recommendations have been followed and we have no trouble browsing across the subnets; but all of the failures I'm writing about occur on the subnet which is remote from the one on which the Samba PDC resides. None of the samba logs associated with any of the several NT workstations on the local subnet with the Samba machine show this error. I can't see how that would matter, given that the inter-process oplock break requests are simply UDP communications and don't use subnet broadcasts - unless I'm mistaken, a very real possibility. :-) Does anyone have a hint on what might cause this, how to troubleshoot it more fully, or if it's really nothing to worry about? Ray Simard
Ray Simard
2002-Dec-24 10:48 UTC
[Samba] Oplock break request failures: some additional info
I checked a little more carefully and noticed that many, though not all, of the occurrences of failed oplock breaks are followed by the message that you see here, "... Deleting it to continue." Looks a little scary; does it mean it's deleting the oplock or deleting the file? Here's a chunk from one of the log files, for the machine called mon6. log.mon6: request_oplock_break: no response received to oplock break request to pid 1084 on port 2846 for dev = 309, inode = 10050, file_id 11 log.mon6: request_oplock_break: no response received to oplock break request to pid 1084 on port 2846 for dev = 309, inode = 40228, file_id 17 log.mon6: request_oplock_break: no response received to oplock break request to pid 1084 on port 2846 for dev = 309, inode = 40221, file_id 21 log.mon6: request_oplock_break: no response received to oplock break request to pid 301 on port 2775 for dev = 309, inode = 42243, file_id 35 log.mon6: request_oplock_break: no response received to oplock break request to pid 3477 on port 3592 for dev = 309, inode = 50280, file_id 43 log.mon6: open_mode_check: exclusive oplock left by process 3477 after break ! file nms097/profile/Recent/42565.doc.lnk, dev = 309, inode = 5 0280. Deleting it to continue... log.mon6: request_oplock_break: no response received to oplock break request to pid 6002 on port 4707 for dev = 309, inode = 30168, file_id 16 log.mon6: open_mode_check: exclusive oplock left by process 6002 after break ! file nms097/profile/Application Data/Microsoft/Office/Recent/C ORRECT SPELLING REFERENCE LIST Cover.doc.LNK, dev = 309, inode = 30168. Deleting it to continue... log.mon6: request_oplock_break: no response received to oplock break request to pid 6002 on port 4707 for dev = 309, inode = 30239, file_id 17 log.mon6: open_mode_check: exclusive oplock left by process 6002 after break ! file nms097/profile/Application Data/Microsoft/Office/Recent/4 2577-B.doc.LNK, dev = 309, inode = 30239. Deleting it to continue... log.mon6: request_oplock_break: no response received to oplock break request to pid 10390 on port 2658 for dev = 309, inode = 42243, file_id = 150
On Tue, 2002-12-24 at 11:37, Ray Simard wrote:> I hope someone can enlighten me on this. > > Situation: NT network, Samba PDC, about 20 NT 4.0 workstations. log(s).smbd > are created per machine for easier analysis (as log.smbd.<NetBios Name>). > > Not often, but often enough to be of concern, are errors in > request_oplock_break that seem to indicate that another smbd process that > should be listening for break requests on a UDP socket isn't, or isn't > responding. Some time ago, for some very strange reason, the system was > configured with share modes off, which caused these errors to occur > constantly. That was corrected and now they are infrequent, but not > infrequent enough, I suspect, to ignore. > > One possibly significant fact: there are two subnets. The cross-subnet > browsing recommendations have been followed and we have no trouble browsing > across the subnets; but all of the failures I'm writing about occur on the > subnet which is remote from the one on which the Samba PDC resides. None of > the samba logs associated with any of the several NT workstations on the > local subnet with the Samba machine show this error. I can't see how that > would matter, given that the inter-process oplock break requests are simply > UDP communications and don't use subnet broadcasts - unless I'm mistaken, a > very real possibility. :-) > > Does anyone have a hint on what might cause this, how to troubleshoot it more > fully, or if it's really nothing to worry about?Oplock breaks are notified to client machines, and then clients must answer in a given time (oplocks regards client caching). If clients fail to answer in time, the server must consider them broken/dead/whatever and break the oplock itself. This of course means that it could have unconsistent data on disk, but nothing can be done. You have slow links, you may want to rise oplock breack times, but then you may experience slower startup fo rapplications or slow file opening. You may try with: oplock break wait time But be sure you understand what this means, read carefullt the man pages and use at your own risk :-) Simo. -- Simo Sorce - idra@samba.org Samba Team - http://www.samba.org Italian Site - http://samba.xsec.it
On Tue, Dec 24, 2002 at 02:37:14AM -0800, Ray Simard wrote:> I hope someone can enlighten me on this. > > Situation: NT network, Samba PDC, about 20 NT 4.0 workstations. log(s).smbd > are created per machine for easier analysis (as log.smbd.<NetBios Name>). > > Not often, but often enough to be of concern, are errors in > request_oplock_break that seem to indicate that another smbd process that > should be listening for break requests on a UDP socket isn't, or isn't > responding. Some time ago, for some very strange reason, the system was > configured with share modes off, which caused these errors to occur > constantly. That was corrected and now they are infrequent, but not > infrequent enough, I suspect, to ignore.What OS are you running Samba on ? Jeremy.