Streams "wait" forever on NFS

[Peter Heidbreder]

We have an application that is running a Java application (1,4.2) on a HPUX 11.23 system. It uses an NFS mount point for data. The application has a wait reason in glance of STRMS. There is no pressure on the system that I can see. I have updated the system with the most current NFS and streams patches as well as made most of the recommended parameter changes for NFS.

If we have the system use the local directory everything is fine. I suspect it may be a Java or Oracle issue but want to see if there is anything else I should look at to make it work using the NFS mount point.

[Steven E. Protter]

Shalom,

Normally the cause of this problem is due to disruption of network or a problem on the NFS server.

Normally you can restart NFS on your system and correct this problem.

/sbin/init.d/nfs.client stop
/sbin/init.d/nfs.client start

You may also need to stop nfs.server and nfs.core if its a really bad disruption.

Always stop client then server then core and restart in reverse order.

A reboot accomplishes the same thing.

SEP

[Peter Heidbreder]

I have tried that and the problem still exists when we test again. I am thinking it may be some sort of locking issue. Would it be a good idea to add the NFS server using short and long names to the /var/statmon/sm directory? Along those same lines should I be seeing links from ipv4.ip_of_client on the NFS server in /var/statmon/sm?

[Peter Heidbreder]

The problem turned out to be a file locking issue. The latest version of ServiceGuard has an additional file used by hanfs.sh. The
hanfs.sh turns on locking with the "NFS_FILE_LOCK_MIGRATION=1" variable and the script is set in the NFS_FLM_SCRIPT="${0%/*}/nfs.flm" variable. In the nfs.flm file you need to assign the location for the "sm" directory. It need to be located on one of the nfs mount points. This essentially picks up the info from /var/statmon/sm so it can be used when it fails over.