sean@compu-aid.com wrote:>
> To any one who is using Red Hat Linux 6.0 (or, presumably, any glibc2.1
> system)
>
> I recently installed a new RH 6.0 system on Intel. After installing my
> samba and my network application I noticed that I was experiencing oplock
> problems that were not present with the same version of Samba on my RH 5.2
> systems and caused my application to not function. Since the problem
> seems to be with oplocks I don't know if this could cause data
> corruption/inconsistency or not but I would assume so. I have tested this
> both with Samba 2.0.3 (that ships with RH) and also Samba 2.0.4b. I have
> also tried compiling Samba fresh (as opposed to using the binary RPMs).
>
> Evidence of the problem are log entries like the following (gotten at
> debug level=3 and higher)
>
> [1999/05/22 14:42:06, 3] lib/util.c:fcntl_lock(2658)
> fcntl lock gave errno 11 (Resource temporarily unavailable)
>
> It seems that I only see "fcntl" when this error occurs so that
may be a
> safe expression to grep for if you want to look for it. I had quite a few
> of these lines. Presumably my application trying to get to it's files
> before it died a horrible death.
>
> There are two fixes I've found for this so far:
>
> 1 - set oplocks = false for the system. The downside of this is that with
> oplocks disabled you will have anywhere from a minor to a massive
> performance hit.
>
> 2 - The better fix, IMHO, is to do the following
>
> rpm -Uvh /path-to-redhat-6.0/compat-glibc-5.2-2.0.7.1.i386.rpm
>
> edit /etc/rc.d/init.d/smb
>
> In the "start)" case add
> LD_LIBRARY_PATH=/usr/i386-glibc20-linux/lib
> before the "daemon smbd -D" line
>
> and then add
> LD_LIBRARY_PATH> after the "daemon nmbd -D" line
>
> (note: I haven't tried the above in a script yet, just manually with
> manually executing smbd/nmbd but I see no reason why it would be any
> different in a script)
>
> As best I understand this, this points the dynamic linker to look in the
> old glibc2.0 directory first to resolve objects. In this case it makes
> Samba run as if it were still on a glibc2.0 (ie: RH 5.2) system and things
> work fine again. It seems to run just fine like that and you can leave
> oplocks enabled so your users/clients/self stop yelling at you :)
>
> I don't know if this is a Samba bug for not following some new glibc2.1
> API change or just a glibc2.1 bug. But Samba is the only application
I've
> had problems with so far so I'm starting here.
>
> samba-bugs has been cc'd and I am also reporting this as a bug to Red
Hat.
> I consider this a pretty severe problem.
>
> If anyone has any questions please feel free to ask me.
Ok, I'm pretty sure what's going on here. I'm also CC:ing
this to Ulich Drepper who is the maintainer of the glibc
library at Cygnus & also Erik Troan at RedHat.
The problem is that WinNT has a bug in which it sends 64
bit lock range requests to systems that only have 32 bit
lock ranges available, despite being told via the protocol
not to do so (just another area they never tested I guess).
Samba is fully 64-bit clean on a 64 bit system and will
work fine on these systems. Unfortunately x86 linux is only
a 32 bit system. Samba 2.0.4 has a fix in it in that if it
detects it is running on a 32-bit system it will 'fold' the
64 bit lock range into 32 bits as best it can. It needs to
do this as applications like Word and Excel need byte range
locks to conflict correctly in order to detect multiple opens
on a file. This works all well and good on glibc2.0 systems
(which Samba detects as 32 bit lock aware).
But glibc2.1 lies on a Linux x86 system :-). It tells Samba
that it can do 64 bit lock reqests. It can't. What glibc2.1
does is just drop the top 32 bits of any range request. This
causes the bottom half of the lock ranges to collide with
earlier lock ranges - hence the messages you are getting.
Now Samba has the code to work correctly with glibc2.1, it
just needs to stop believing that glibc2.1 is a 64 bit lock
aware library on a 32 bit system. Personally I think this is
a glibc2.1 bug on x86 Linux. As Samba already contains the
correct code (as evidenced by the fact it works with the
glibc2.0 libraries) we need to find a way for the Samba
autoconf scripts to detect lying libc libraries and turn
on the 32-bit workaround automatically on Linux x86 glibc2.1.
Regards,
Jeremy Allison,
Samba Team.
--
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------