Odd messages from NFS

[Brian Reiter]

Hi folks

We're getting a couple of odd messages from the NFS server in the operator log:

svcktcp_reply: mbuf_send returned 32

and

rfs_dispatch: sendreply failed IP address: 10.51.1.140

They seem to be caused when a linux client attempts (and fails) to mount a couple of mount points.

The OpenVMS version is 7-32 (Update 0500) with TCPIP Services V5.4 - ECO 5. I know these are ancient but at this moment an upgrade is not feasible.

OpenVMS based clients which are configured appear to work correctly.

Some ideas about what the messages mean would be appreciated.

I've attached (with any luck) the full text of the log messages.

cheers

Brian

[Hoff]

The older nfs versions found on OpenVMS can be unstable and can tend to be very fussy around the configuration details, in my experience. There have been reports of issues with AIX, Mac OS X and Linux NFS clients with the older bits.

As for some suggestions, read:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=984439

And do look to ECO to current, or (better) upgrade.

If persisting in the current course is mandated here, do say hello to Captain Ahab for me, and then try forcing NFSv2 and UDP access if and as your particular whale, err, client allows. :-)

[Brian Reiter]

Cheers Hoff, :)

I always proffer my regards to Captain Ahab (in this case the UK government). However after further discussion with the engineers things do turn a but murkier....

The problem described above occurs when our system runs on a DS10. When using a copy of the delivery system (a DS15 running the same OS version and patches) everything seems to be OK.

So far we've spotted no obvious differences between the configuration of the two systems, the TCPIP configuration related files have been checked, the startup procedures are identical (or appear to be).

Any clues as to what these odd messages relate to? Or is it just a bizarre timing issue?

[Jim_McKinney]

The "32" is a standard errno return code that equates to "EPIPE" or a "broken pipe". I'll presume that those two messages are paired - so, though I know nothing of the internals of NFS, I'd guess that the NFS server is returning the EPIPE in reaction to the absence of an acknowledgement of a prior send to 10.51.1.140. Could it be that the network is lossy?

[Hoff]

Could be the network, could be the client, could be the NICs, or most anything...

Check the nfs server configuration, too. I'd check in the nfs server directory and in the NFS setup inside the TCPIP> utility.

Could also be that the messages were somehow disabled.

[Wim Van den Wyngaert]

Found this (could be useful for other message too):

http://www.helsinki.fi/atk/unix/dec_manuals/DOC_40D/APS2SCTE/DOCU_017.HTM


The server is out of memory and cannot process or reply to a request.

The server cannot find a route to the source.

Some other network-related problem.

Wim