Comment 18 for bug 643289

I think this bug is in a somewhat confused state at the moment. I have tried now to reproduce the problem using oneiric, which as of the latest SRU had the same upstart job handling as in lucid. (Apparently we had already SRUed for this issue, and I had subsequently forgotten!) The only problem I've been able to reproduce is that caused by trying to start idmapd before /usr is mounted, and the job failing to start as a result. I have a workaround (not a fix) for this, which I will SRU for shortly. But with the current revision of upstart jobs (which has rpc_pipefs as an 'instance' job that starts separately for, and blocks, each of gssd and idmapd), I definitely cannot reproduce this most recently described problem:

 Feb 28 22:20:43 test rpc.idmapd[901]: main: open(/var/lib/nfs/rpc_pipefs/nfs): No such file or directory

I can't reproduce it even when adding a 10 second delay to rpc_pipefs as suggested.

Now, the SRU that addressed this issue, nfs-utils 1:1.2.0-4ubuntu4.1, was published to lucid-updates on January 27. Is it possible that the people who were reporting this problem after that date had not yet applied the SRU fix?

Steve, you mention idmapd failing to start for you in a configuration where there are no nfs mounts in /etc/fstab. How does it fail to start? Does it give you a job in state 'start/running' with no PID (which would be the /usr race), or does it give you the "/var/lib/nfs/rpc_pipefs/nfs: No such file or directory" log error (which I can only reproduce with -4ubuntu4)? You mentioned you were going to try to find another reproducer case - did you succeed?