MMapFile: File locking failed with error code 37

[Jerry Feldman]

Got a response from Red Hat to restart the lock daemons on both client=20
and server. This worked even though I had done this before. So, I would=20
assume case is closed.

On 02/04/2009 07:33 AM, Jerry Feldman wrote:
> Thanks. We submitted an official bug report to Red Hat. Under the=20
> rules I must work under, all my systems must be running RHEL 5.2=20
> unpatched.  While we have a mix of systems in Toronto with both=20
> Solaris and older RHEL servers, we use the NFS server for both=20
> development and server. I'll try to grab a more recent kernel when I=20
> get a chance to reboot. I can actually run a test on another system=20
> first just to verify that the new kernel fixes the problem.
>
> On 02/03/2009 08:52 PM, Nuno Sucena Almeida wrote:
>> Hi Jerry,
>>
>>  as I mentioned, our problem was with locking and after some searching=

>>  on the lkml , reading about similar reports and actually seeing a
>>  diff on the kernel git repository, I upgraded the kernel on the
>>  server and stopped having problems with NFS. It might be the same
>>  issue that you have and at that time I was surprised that it took
>>  that long for the problem and a fix to show up. I actually don't
>>  remember the circustances where the client machines would start to
>>  complain, but it wasn't obvious, although probably I used strace to
>>  reach the conclusion that some weird thing was going on with locking.=

>>               Good luck!,
>>             Nuno
>>
>> On Thu, Jan 29, 2009 at 01:08:18PM -0500, Jerry Feldman wrote:
>> =20
>>> I have a bit more information. I was able to find the lines of code, =

>>> and it has nothing to do with mmap(2). The problem is with fcntl,=20
>>> and only when  int fcnt =3D fcntl(fd, F_SETLK, &fl); /* fails when NF=
S=20
>>> server is RHEL 5.2    =20


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846