Building on Clint Byrum's work on bug #525154, I'm much closer now to
understanding a possible solution for this issue, but it's going to
require some coordination.  Details:

- the current idmapd job starts on 'local-filesystems or mounting TYPE=nfs4' 
because it needs to start whenever an nfs4 filesystem is mounted and it also 
needs to wait until /usr and /var/lib are available before starting up (/usr 
because idmapd is located in /usr/sbin; /var/lib because it uses 
/var/lib/nfs/rpc_pipefs).  The only way to wait for /usr and /var/lib is by 
waiting for 'local-filesystems'; it's *possible* that one or both of these 
filesystems is not local, but that's a local configuration error anyway.
- the start condition used here is buggy.  If local-filesystems is emitted 
first, idmapd will proceed to start up without blocking any further 'mounting' 
hooks.  If 'mounting TYPE=nfs4' is emitted first, there is no way to make the 
job wait for the local-filesystems signal to be received, which can cause the 
job to try to start before the filesystem is usable and wind up in an 
inconsistent state when idmapd aborts.
- using jobs in the style of portmap-wait and statd-mounting, it is possible to 
construct a set of jobs that will only start idmapd on local-filesystems, and 
*also* block any nfs4 mounts until idmapd is started.
- unfortunately, it appears that mountall itself blocks on the result of the 
'mounting' hook before doing any further processing of *any* mount points, with 
the result that, if 'local-filesystems' has not already been emitted at the 
time it tries to mount the first nfs4 filesystem, we end up in a deadlock: the 
'mounting' hook is waiting for idmapd to start; idmapd is waiting for 
local-filesystems to be emitted; and mountall is waiting for the 'mounting' 
hook to return before going on to do any other mounts.

I see three possible solutions here.

1. Change mountall to be able to do other work while waiting for the 'mounting' 
hook to return.  Conceptually I don't see any reason this isn't possible, so it 
should just be a matter of code reordering.
2. Change mountall to special case nfs4 mounts so that they are never handled 
until after local-filesystems is emitted.  Yuck for the special-casing, though 
conceptually not actually different from what we're trying to achieve through 
the nfs-common upstart jobs.
3. Move idmapd and its dependencies (libevent; libnfsidmap, 
/usr/lib/libnfsidmap/) to the root filesystem (/sbin, /lib) and move 
/var/lib/nfs/rpc_pipefs to /var/run/nfs/rpc_pipefs.  The latter may be correct 
in its own right (I'm pretty sure there's nothing on this in-kernel mount point 
that would count as 'persistent state'); the former doesn't even cover all 
cases unless we also move the kerberos+ldap stack to /lib, due to 
/usr/lib/libnfsidmap/umich_ldap.so.

I believe option 1 is the most straightforward to SRU and is correct per
se, although parts of 3 are probably worth pursuing in their own right
as part of an overall effort to improve FHS compliance.

** Also affects: mountall (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: mountall (Ubuntu)
       Status: New => Triaged

** Changed in: mountall (Ubuntu)
   Importance: Undecided => High

** Changed in: mountall (Ubuntu)
     Assignee: (unassigned) => James Hunt (jamesodhunt)

** Changed in: nfs-utils (Ubuntu)
     Assignee: (unassigned) => Steve Langasek (vorlon)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289

Title:
  idmapd does not starts to work after system reboot

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to