samba - Nov 1998 - SOLARIS_2.6: request_oplock_break

I saw a little discussion about this a few weeks ago but nothing concrete.
We're running samba-1.9.18p8 under Solaris 2.6x86. I am periodically
getting the following in the logfiles, usually _many_ at a time:

1998/11/03 14:42:00 request_oplock_break: no response received to oplock
break request to pid 5411 on port 40884 for dev = 1980040, inode = 33c4d

When I look up the PID (in this case 5411) I get the following:

ps -ef | grep 5411
    root  5573  5411  0                   0:00 <defunct>
  jwt001  5411  8126  0 14:13:37 ?        0:02 /usr/local/samba/bin/smbd

In looking up this PID in the logfiles (for the connection associated with
it:

1998/11/03 14:13:38 bowlab13 (147.138.110.23) connect to service netlogon
as user jwt001 (uid=9785,gid=60) (pid 5411)

1998/11/03 14:13:47 bowlab13 (147.138.110.23) connect to service profiles
as user jwt001 (uid=9785,gid=60) (pid 5411)

1998/11/03 14:13:53 bowlab13 (147.138.110.23) closed connection to service
netlogon

1998/11/03 14:13:57 bowlab13 (147.138.110.23) connect to service netlogon
as user jwt001 (uid=9785,gid=60) (pid 5411)

check_oem_password: incorrect password length (402434033).
check_oem_password: incorrect password length (402434033).

Note: I've seen this same problem without the check_oem_password errors as
well, so I don't know that they're involved.

Basically what it looks like to me is that an smbd process is spawning a
child which goes defunct for some reason I have yet to determine and the
smbd process hangs out there waiting for the child. Of course the child is
never going to answer being defunct, so the parent smbd process sticks
around and keeps its oplocks.

I can fix an occurance of this by manually killing the offending smbd
process, but I'd like to be able to stop this from happening altogether. 

Has anyone else encountered this or something similar? Is it something
fixed perhaps in samba2 that could be patched in 1.9.18p8/10?

 ----------------------------------------------------------------------
  Douglas K. Fischer    DFischer@Bridgewater.EDU      (540) 828 - 5343
  Network Systems Engineer   C. E. Shull Information Technology Center
  College Box 36        Bridgewater College      Bridgewater, VA 22812
 ----------------------------------------------------------------------

Hello,

I have a similar problem, when accessing a samba share from
a DOS PC (smb1.9.18p8, Linux 2.0.35, gcc 2.7.2.1).
It has nothing to do with the password file. I just want to
copy files from DOS to Samba or delete files on the Server.
(I put the output of smbstatus and a level 10 log at the end
of the message.)

I followed the discussion on this list, but didn't find any
solution to this problem. But I found something in the
announcement of Samba2 beta:
> 5). Cross protocol data integrity
> ---------------------------------
> An open function interface has been defined to allow 
> "opportunistic locks" (oplocks for short) granted by Samba
> to be seen by other UNIX processes.  This allows complete
> cross protocol (NFS and SMB) data integrety using Samba
> with platforms that support this feature.
Is this error a problem of "cross protocol data integrety"?
I export this share via nfs to another Linux box as well.
Then maybe changing to Samba2 would solve the problem?


TIA
M.Geigl

smbstatus:
Samba version 1.9.18p8
Service      uid      gid      pid     machine
----------------------------------------------
bodden       geigl    bodden   23064   pcmei7  
(141.53.32.128) Wed Nov 25 17:51:35 1998

Locked files:
Pid    DenyMode   R/W        Oplock           Name
--------------------------------------------------
23064  DENY_DOS   RDWR       EXCLUSIVE+BATCH 
ELLI.SAV/SWEN/PL50W455.3D   Wed Nov 25 17:54:00 1998


logfile:
1998/11/25 18:03:10 pcmei7 (141.53.32.128) connect to
service bodden as user ge
igl (uid=500,gid=101) (pid 23084)
1998/11/25 18:03:10 tconX service=bodden user=geigl cnum=102
size=51
smb_com=0x73
smb_rcls=0
smb_reh=0
smb_err=0
smb_flg=128
smb_flg2=1
smb_tid=102
smb_pid=14981
smb_uid=100
smb_mid=609
smt_wct=3
smb_vwv[0]=117 (0x75)
smb_vwv[1]=41 (0x29)
smb_vwv[2]=0 (0x0)
smb_bcc=0
write_socket(7,55)
write_socket(7,55) wrote 55
got smb length of 65
got message type 0x0 of len 0x41
1998/11/25 18:03:10 Transaction 3 of length 69
size=65
smb_com=0x6
smb_rcls=0
smb_reh=0
smb_err=0
smb_flg=0
smb_flg2=0
smb_tid=102
smb_pid=14981
smb_uid=100
smb_mid=641
smt_wct=1
smb_vwv[0]=6 (0x6)
smb_bcc=28
[000] 04 5C 45 4C 4C 49 2E 53  41 56 5C 53 57 45 4E 5C 
.\ELLI.S AV\SWEN\
[010] 50 4C 35 30 57 34 35 35  2E 33 44 00             
PL50W455 .3D.
switch message SMBunlink (pid 23084)
become_user uid=(0,500) gid=(101,101)
chdir to /bodden/bodden
reply_unlink : \ELLI.SAV\SWEN\PL50W455.3D
unix_clean_name [./ELLI.SAV/SWEN/PL50W455.3D]
checking PL50W455.3D for 8.3
dos_mode: 102 ELLI.SAV/SWEN/PL50W455.3D
is_in_path: ELLI.SAV/SWEN/PL50W455.3D
is_in_path: no name list.
dos_mode returning a
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:03:10 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:03:14 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:03:14 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:03:14 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:03:42 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:03:42 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:03:42 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:03:46 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:03:46 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:03:46 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:04:14 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:04:14 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:04:14 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:04:18 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:04:18 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:04:18 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:04:46 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:04:46 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:04:46 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f
1998/11/25 18:04:50 request_oplock_break: no response
received to oplock break 
request to pid 23064 on port 1871 for dev = 804, inode 9280f
1998/11/25 18:04:50 request_oplock_break: broke oplock.
get_share_modes Read share mode 0x2 pid=23064
get_share_modes: file with dev 2052 inode 600079 -> 1
entries
check_file_sharing: breaking oplock (3) on file
ELLI.SAV/SWEN/PL50W455.3D, dev 
= 804, inode = 9280f
1998/11/25 18:04:50 request_oplock_break: sending a oplock
break message to pid
 23064 on port 1871 for dev = 804, inode = 9280f

-- 
-------------------------------------
Martin Geigl
Universitaet Greifswald
Institut fuer Physik
Domstr. 10a
17489 Greifswald
Tel.: +49-3834-864745
Fax: +49-3834-864701
-------------------------------------

> Hi
> 
> We are having some problems - the majority of our files require ascii
> transfers between our unix servers and PCs. They are however being
> transferred as binary for some reason even though they are just plain
> text files. This means (when going from unix to pc) the files come down
> without a carriage return at the end of lines. And when going from pc to
> unix they end up with  ^M on the end of each line. Anyone have any
> ideas?
> 
> TIA
Hmmmm... I may be wrong, but I dont think I am....
Anyway, it sounds like you NEED binary mode to transfer these files.
I think it is ASCII mode which is doing the CR/NL conversion to you.

jim

Jim Kendall wrote:
> 
> > Hi
> >
> > We are having some problems - the majority of our files require ascii
> > transfers between our unix servers and PCs. They are however being
> > transferred as binary for some reason even though they are just plain
> > text files. This means (when going from unix to pc) the files come
down
> > without a carriage return at the end of lines. And when going from pc
to
> > unix they end up with  ^M on the end of each line. Anyone have any
> > ideas?
> >
> > TIA
> 
> Hmmmm... I may be wrong, but I dont think I am....
> Anyway, it sounds like you NEED binary mode to transfer these files.
I assume you copy to a *samba* share, *not* using ftp. In samba there is
no explicit binary/ascii mode ...
Nevertheless, when you ftp your file (binary or ascii mode) you will get
the same result due to the different CR/LF <-> NL conventions between
these different operating systems.
> I think it is ASCII mode which is doing the CR/NL conversion to you.
> 
> jim
NO - there is *NO* conversion done here. The file is transmitted as is!

When you copy an MSDOS ascii file to the unix-share ... it is still an
MSDOS file with all the MSDOS conventions and it can be viewed with an
MSDOS editor.

When you view this file with an unix editor, you will see the MSDOS
end-of-line convention ^M.

The only thing I see is:
When you exchange files between these operating systems, you will have
to run some conversion-util on these files.

best regards
juergen

-- 
snail: 	ANZER GmbH - Pieperstr. 14 - 32791 Lage - Germany
email: 	rick_@t-online.de
voice:	(0049) 5232 / 9777-21
fax:	(0049) 5232 / 78094