Bug 511278

Description of problem:
When attempting to mount an NFSv4 share from a server on a RHEL5 client, the file system exhibits odd behaviour, primarily visible through the /proc/self/exe symlink. After an fstat on a file from an NFSv4 share, the phrase ' (deleted)' is appended to what the file system thinks the files name is. Thus, /proc/self/exe for '/path/to/process' points to '/path/to/process (deleted)' (which is an invalid symlink). 

This is particularly problematic when running programs off of an NFSv4 share, as programs (such as the java JDK) attempt to use /proc/self/exe to work out where they are, and fail when the (deleted) is added. A temporary solution is to copy the file with the phrase (deleted) in the filename, but this is far from ideal.

The problem is client side, and not server side, and appears to be in the kernel (see additional info). A Fedora 10 client can mount the server without problems. Likewise, a Fedora 10 server (or any other setup running an NFsv4 server) mounted on a RHEL client produces the same problem.

How reproducible:
Always on a RHEL5 client - accross various different versions and configutrations of Red Hat

Steps to Reproduce:
1. Set up an NFSv4 server and export, for example, /test
2. Mount /test on a RHEL5 client using NFSv4
3. Execute a program that demonstrates the broken behaviour (see below)

Demonstrating the broken behaviour: 

The broken behaviour can easily be demonstrated with a simple C program:
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main()
{
        char buf[1024];
        int len = readlink("/proc/self/exe", buf, sizeof(buf));
        printf("/proc/self/exe = %s\n",buf);
}

Compiling and running the program produces the following output (note how it alternates between the correct response and broken response)
test@tester /test $ ./a.out
/proc/self/exe = /test/a.out (deleted)·
test@tester /test $ ./a.out
/proc/self/exe = /test/a.out
test@tester /test $ ./a.out
/proc/self/exe = /test/a.out (deleted)·
test@tester /test $ ./a.out
/proc/self/exe = /test/a.out
test@tester /test $ ./a.out
/proc/self/exe = /test/a.out (deleted)·

The broken behaviour can also be seen with java. For example, extract the java JDK into /test and attempt to run 'java' or 'javac'. The first execution will fail, subsequent executions until a stat will work, then failure will again occur.

test@tester test $ ./java -version
execve(): No such file or directory
Error trying to exec test/java (deleted).
Check if file exists and permissions are set correctly.

test@tester test $ ./java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode)
test@tester test $ ./java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode)
test@tester test $ ./java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode)

test@tester test $ stat ./java > /dev/null

test@tester test $ ./java -version
execve(): No such file or directory
Error trying to exec test/java (deleted).
Check if file exists and permissions are set correctly.

test@tester test $ ./java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode)

---
  
Actual results: /path/to/file (deleted)


Expected results: /path/to/file


Additional info: It seems that when the problem occurs, no request to the NFSv4 server is made from the client (when deleted is appended). When the attempt occurs again, a request is made and it works (no deleted). There does not seem to be anything else obvious or apparent to the problem in the NFS server log or client log different to a working system. 

The problem appears to be in the kernel, not in the software based nfs-utils. Using the same nfs-utils that work on a Fedora 10 system on the RHEL system still results in the same problem.

The problem does not occur on a Fedora 10 client mounting the same server.