I'm continuing to dig down on this one since it is still biting. The one thing that is certain is that with the patch applied the error from rpc.idmapd doesn't appear in the syslog. Here's logging *without* the patch, using the archive packages.
So, "Pipefs-Directory" is the culprit. I don't know when that was set but it is obviously the reason for the issue.
I think the reason that the patched 'blkmapd' solves it is because I build and install updated packages, and the postinst job changes the idmapd.conf file.
I found this which seems to indicate a package upgrade issue but I wasn't notified:
Verbosity = 0
<<<<<<< Current
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = lan.eddie.tj
||||||| Older
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
=======
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
# Domain = localdomain
>>>>>>> New
I'm continuing to dig down on this one since it is still biting. The one thing that is certain is that with the patch applied the error from rpc.idmapd doesn't appear in the syslog. Here's logging *without* the patch, using the archive packages.
Working on Precise amd64.
$ apt-cache policy nfs-common
nfs-common:
Installed: 1:1.2.5-3ubuntu3
Candidate: 1:1.2.5-3ubuntu3
/etc/fstab contains:
10.254. 251.1:/ Library /home/all/Library nfs4 _netdev,auto,user 0 0
I wrapped /usr/sbin/ rpc.idmapd and blkmapd with shell scripts to capture their launch and environment at boot time into /var/log/rpc.log
$ cat /var/log/rpc.log local/sbin: /usr/local/ bin:/usr/ bin:/usr/ sbin:/sbin: /bin EVENTS= local-filesyste ms MOUNTPOINT= /run/rpc_ pipefs
rpc.idmapd called from parent PID 1
TERM=linux
PATH=/usr/
PWD=/
SHLVL=1
UPSTART_INSTANCE=
UPSTART_
UPSTART_JOB=idmapd
PIPEFS_
_=/usr/bin/env
Sep 2 16:01:23 hephaestion rpc.idmapd. real[3869] : libnfsidmap: using domain: lan.eddie.tj real[3869] : libnfsidmap: Realms list: 'LAN.EDDIE.TJ' real[3869] : libnfsidmap: loaded plugin /lib/libnfsidma p/nsswitch. so for method nsswitch real[3880] : Expiration time is 600 seconds. real[3880] : Opened /proc/net/ rpc/nfs4. nametoid/ channel real[3880] : Opened /proc/net/ rpc/nfs4. idtoname/ channel real[3880] : main: open(/var/ lib/nfs/ rpc_pipefs/ nfs): No such file or directory
Sep 2 16:01:23 hephaestion rpc.idmapd.
Sep 2 16:01:23 hephaestion rpc.idmapd.
Sep 2 16:01:23 hephaestion rpc.idmapd.
Sep 2 16:01:23 hephaestion rpc.idmapd.
Sep 2 16:01:23 hephaestion rpc.idmapd.
Sep 2 16:01:23 hephaestion rpc.idmapd.
which confirms the use of the old path.
I ran idmapd with strace to see why it is using that path and found this:
... etc/idmapd. conf", O_RDONLY) = 3 var/lib/ nfs/rpc_ pipefs/ nfs", O_RDONLY) = -1 ENOENT (No such file or directory)
5026 open("/
...
5026 open("/
The idmapd.conf is:
$ cat /etc/idmapd.conf
[General]
Verbosity = 0 nfs/rpc_ pipefs
Pipefs-Directory = /var/lib/
Domain = lan.eddie.tj
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
So, "Pipefs-Directory" is the culprit. I don't know when that was set but it is obviously the reason for the issue.
I think the reason that the patched 'blkmapd' solves it is because I build and install updated packages, and the postinst job changes the idmapd.conf file.
I found this which seems to indicate a package upgrade issue but I wasn't notified:
-rw-r--r-- 1 root root 385 Apr 18 10:54 /etc/idmapd. conf.merge- error
[General]
Verbosity = 0 nfs/rpc_ pipefs nfs/rpc_ pipefs
<<<<<<< Current
Pipefs-Directory = /var/lib/
Domain = lan.eddie.tj
||||||| Older
Pipefs-Directory = /var/lib/
Domain = localdomain
=======
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
# Domain = localdomain
>>>>>>> New
[Mapping]
Nobody-User = nobody conf.merge- error (END)
Nobody-Group = nogroup
/etc/idmapd.