rpc..lockd unsupported nlm4_call

[David Nixon]

I have some NFS lock hangs with an 11,00 client
attempting to lock on an 11.11 server. On the
client locking is generally required to support 'procmail' activity.

Re-starting the lockd on the client generates
a bunch of messages: "rpc.lockd: 3 not supported in nlm4_call". One other thing that seems significant is that lockd tracing on the
client reveals a large message queue.

Can anyone explain the significance of those
unsupported "nml4" calls?

Thanks,
DavidN

[Steven E. Protter]

Shalom,

The locking requested, MAY require NFS v4, which is only installable with HP-UX 11i v2 or many Linux distributions.

Google affectionatly referred to as "the one above" has no help on this error.

SEP

[Kent Ostby]

David --

I would check your revision of the NFS/ONC patches on both systems as this sounds like something that might have to do with a version interaction problem.

I cannot find anything in the internal HP database with that exact message although there were some issues with how long nml4 calls were taking when it first came out that were fixed in patches.

swlist -l product | grep NFS

will show you the patches on your box now. From there you can check the latest of that type of patch available from HP.

[Prashant Zanwar_4]

Are you using any file locks? which application is expecting and is not in place?
Also if you are restarting rpc, also do a clear_locks, which is usually safe..
As assisted by other folks check on system patches for NFS ..
Also you might be interested in generating a debug log and sending to HP.

good luck
hope it helps
Prashant

[David Nixon]

At the moment there in't much latitude for
version updates I can only go from PHNE_30377 -> PHNE_31096 on the 11.00 client - the 11.11
server is already at PHNE_33971.
Restarting statd/lockd on the client alone
doesn't re-enable locking; to that particular server: running 'clear_locks -s svr' on the client does the trick.
I'm sure version 4 will the solution
to all of our NFS locking problems - when
it's stable..
Thanks for the suggestions. I'll keep
this open for a few more days, in case I
have more to report.

DavidN

[Todd Whitcher · Accepted solution]

Hi David,

Here is some info on clear_locks:

When an NFS server receives a lock request from a NFS client, it caches the
port number for the NFS clientâ s rpc.lockd program. The NFS server will
continue to use this port number unless it receives an update from the client
that its port number has changed. It is possible for the NFS client data to
become corrupt causing the client to fail to send this update to the NFS
server. This creates a case where the NFS server is sending lock messages to
the wrong port on the NFS client causing locks to fail.


You would see that in a network trace, you could compare the lock program reported by rpcinfo -p on the client/server with the port that is being used in the NLM calls/replies in a network trace ( nettl or ethereal etc)


This command should only be used to repair the rare case of a
client crashing and failing to clear held locks. Clearing locks held by an
active client may cause applications to fail in an unexpected manner.

This issue is often seen when users kill rpc.statd and rpc.lockd, clear out the entire contents of /var/statmon/sm and sm.bak and restart rpc.statd/rpc.lockd.//which should be avoided or when a client crashes in these files become corrupt.

Maintaining /var/statmon/sm and sm.bak is a required procedure but the entire contents should not be removed if there are valid lock entries in the directories. The entries are used for crash recovery for NFS file locks.

As an administrator these directories usually have to be checked when IP or hostname changes are made. You simply remove any old hostnames or corrupt entries.

File locking is dependent on name resolution services functioning properly.

So, my guess is that the port numbers for locking changed on the client at some point..causing this issue.

There is an enhancement to 11.11 and 11.23 on its way that allows customers to set a static port for rpc programs.

The patches will be:
PHNE_34550 for 11.23 (subject ot change)
&
PHNE_34662 for 11.11 (subject to change)

They are not released yet

Hope that helps explain your potential issue.

Todd

[David Nixon]

Thanks Todd for pointing out the possibility
of the server not being notified about the client port change. That scenario seems to fit my case.
The client rpc.statd/lockd services were restarted at a time when the network was overloaded.
Subsequently locks to this server would hang
though locks to another server were still working.
Running clear_locks from the client has resolved my lock hangs.