MMapFile: File locking failed with error code 37

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

On 01/26/2009 11:35 AM, Matthew Gillen wrote:
> Jerry Feldman wrote:
>  =20
>> We are having some issues with RHEL 5.2 NFS.  If I run the program on =
a
>> system with local disks, everything works fine, but if I run it on an
>> NFS mounted drive, I get this error. I've tried this on a couple of
>> different systems in my office, on a couple of different directories
>> including my home directory. I have no problem creating files on any o=
f
>> the systems. This problem did not show up when we were running RHEL 4
>> Update 6.
>>    =20
>
> Given your 'ps' output, I'm assuming the answer to this is yes, but if =
on the
> client you do:
>  rpcinfo -p
> and
>  rpcinfo -p <serverHostname>
>
> do you see nlockmgr in both?
>
>  =20
>> Here are the actual error messages:
>> mmap file locking error: No locks available
>> MMapFile: File locking failed with error code 37
>> MMapFile: '/home/gaf/from04.dat.0' has been locked by another process.=

>> MMap file creation failed for file /home/gaf/from04.d
>>    =20
>
> There are two conflicting error messages there.  One indicates that the=
 file
> is already locked (perhaps you copied too much from the other server?).=
  The
> other error message might be that the rlimits are set differently (or t=
hat
> user is running other stuff that uses all his available locks on the RH=
EL 5.2
> box).  You can compare
>  /etc/security/limits.conf
> on the server boxes to see if there are differences (the 'locks' parame=
ter in
> particular).  Or just add an explicit entry in limits.conf for that use=
r to
> set his 'locks' high.
>
> HTH,
> Matt
>
>  =20
First nlockmgr shows up on both the server and client, 3 each udp and tcp=
=2E

The 4 messages is what I get.

It appears that the problem is on the RHEL 5.2 server side. I downgraded =

one of our servers to RHEL 4 Update 6, and exported a directory /fubar.=20
Logged into one of the RHEL 5.2 systems mounted <host>:/fubar /mnt, then =

I ran the same test and I was able to write into that directory.

BTW /etc/security/limits.conf changes had no affect.
ulimit shows
file locks                      (-x) unlimited

I've bumped the issue up to our IT people who may have run into similar=20
issues. We need to run RHEL 5.2 down here because of some of our product =

requirements. We don't want to downgrade the file server to RHEL 4=20
unless it is absolutely necessary. But, since I don't have the official=20
license, I can't put in a bug report.

--=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