[Bug 811823] Re: idmapd upstart job ends in an inconsistent state if /usr is a separate partition

[Steve Atwell]

Steve, I'm looking at your change to gssd.conf and idmapd.conf, and it
looks like you've got a race condition.  You add the following to the
pre-start script of both:

        if ! mountpoint -q "$PIPEFS_MOUNTPOINT"
        then
                mount -t rpc_pipefs rpc_pipefs "$PIPEFS_MOUNTPOINT"
        fi

The problem is that the filesystem could get mounted between when you
check with mountpoint and when you call mount.  And because mount is the
last command in the pre-start script, if it fails then the pre-start
will fail, preventing the job from starting.  I haven't actually seen
this issue, but since two jobs are running this same code around the
same time, it definitely seems like a possibility.

Probably a simple "|| true" on the mount command would be sufficient.
If the mountpoint isn't actually there when rpc.gssd or rpc.idmapd
starts, that process will exit and upstart will retry.

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

Title:
  idmapd upstart job ends in an inconsistent state if /usr is a separate
  partition

Status in “nfs-utils” package in Ubuntu:
  Fix Released
Status in “nfs-utils” source package in Lucid:
  Fix Committed
Status in “nfs-utils” source package in Maverick:
  Fix Committed
Status in “nfs-utils” source package in Natty:
  Fix Committed

Bug description:
  Because the idmapd upstart job uses a script line instead of directly
  exec'ing the server, in the case where /usr is a separate partition
  and not yet mounted at the time the job is started (e.g., because an
  NFS mount is attempted in parallel to an fsck of /usr), the job will
  fail to start and get wedged in a 'start/running' state with no
  associated PID (upstart bug #545673).  If we exec the daemon directly,
  upstart will detect the exec() failure and respawn as needed.

  This partially addresses the problems described in bug #643289, and is
  worth SRUing in its own right even though it doesn't provide a
  complete solution for all users.

  SRU justification:  race conditions in the nfs-utils upstart jobs
  cause NFS client startup to be unreliable in certain configurations in
  lucid and above, a regression vs. pre-upstart releases of Ubuntu.

  Although this upload includes the removal of the rpc_pipefs job
  (moving its functionality into the gssd and idmapd jobs for
  simplicity), the real risk of regression here is very small.  There
  are no changes to the start/stop conditions to the gssd or idmapd
  jobs, only a change to the script rule for the idmapd job.  This
  should have *no effect* except in the case where /usr/sbin/rpc.idmapd
  is missing at the time the job runs - i.e., in the case when /usr has
  not yet been mounted.

  TEST CASE:
  1. configure a system with /usr on a separate partition.
  2. install nfs-common from the release (or -updates) pocket.
  3. configure an NFSv4 mount in /etc/fstab to trigger idmapd to start before /usr is mounted.  (The nfsv4 mount does not have to actually be mountable.  Here is an example entry:
  borges:/	/home/devel	nfs4	sec=krb5i,proto=tcp	0	0
  )
  4. boot and verify with 'service idmapd' that the idmapd service is left in state 'start/running', with no associated process.
  5. install nfs-common from the -proposed pocket and reboot.
  6. verify with 'service idmapd' that the idmapd service has been successfully started, and is in state 'start/running' with an associated pid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/811823/+subscriptions