Shared library issues

[Craig1]

We have been running into an issue recently that we have not been able to explain. We were hoping that HP may be able to shed some light on the issue. We have executables that use shared libraries and are running on an HP PA risk superdome running HP_UX 11.i(uname –a shows: HP-UX “hostname” B.11.11 U 9000/800 1395272773 unlimited-user licence). These executables also use memory locking in their processing. What we have found is that for some selection of shared libraries we are running into an issue when they are located on an NFS mounted directory.
The issue is that the modification time on the shared library is being changed. If we run the executable and point the SHLIB_PATH to and NFS mounted location and the directory is not writable then the executable dies with a page I/O modification error. One of the most recent cases of this is with executables using the mlib libraries lapack and veclib. I have been able to reproduce the behavior with a hello world app. So we figured we would ask the question to see if we may be missing an HP patch related to NFS or if this is the first case of this happening.
The following is a program that causes the issue.
#include
#include
#include

void main()
{
mlockall(MCL_CURRENT);
printf(“hello world”);

}

after compiling this program the following way:
cc hello_world.c –o hello_world –L/opt/mlib/lib/pa2.0 –lveclib –llapack –Wl,+s

we get the executable hello_world with chatr showing that the SHLIB_PATH is enabled and that the executable relies on veclib and lapack. Now if we copy the two shared libraries to a NFS mounted location, non local to the machine, and then change my SHLIB_PATH environment variable to point to this new location, we will see the modification time on the shared library change after we run the executable. This change seems to be what is causing our issue.
An interesting thing to note is that if I make the directory read only by the same user running the executable, it updates the modification time anyway. If we use a different user to make the directory read only and owned by them, then the user running the executable will get a “process “pid” killed due to page I/O modification error” and the mlock fails with an enospc error.
So the question is what is it about the shared library being NFS mounted is causing the modification time to be updated? A diff between the original shared library and the one written to shows no difference, so it is not being changed. And the second question is whether there is a patch to change this behavior already or is this something that can be fixed with a setting or something else that we may be missing?

[Dennis Handly]

Can you run tusc on your process to see what it does?

Can you duplicate it with a different set of shlibs?

>what is it about the shared library being NFS mounted is causing the modification time to be updated?

Have you checked the contents to see if they are modified?

[Craig1]

Can you run tusc on your process to see what it does?
Yes we have done this, it doesn't look like a write out of the process itself, the only open on the shared library is when it is mmap into memory, but it is closed and no writes took place.

Can you duplicate it with a different set of shlibs?
seems like any of the mlib libraries, but they are all large in comparison to others in user lib, so it may be a size related thing.

>what is it about the shared library being NFS mounted is causing the modification time to be updated? This is my original question :)

Have you checked the contents to see if they are modified? yes, the contents don't seem to change. A diff on the original vs the modified seems to be identical.

[Craig1]

I think it may be a size related thing, I found that other libraries that are 8 digits in size exhibit the same behavior.

[Dennis Handly]

>the only open on the shared library is when it is mmap into memory,

And that opens it read only?

Have you made sure you are up to date on patches?

[Craig1]

We verified that we have all recommended NFS related patches based on input from support.

[Dennis Handly]

>We verified that we have all recommended NFS related patches based on input from support.

Perhaps not just NFS. You could need linker/dld or kernel patches.