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

Steve Langasek steve.langasek at canonical.com
Fri Sep 9 12:30:14 UTC 2011


Hi Steve,

On Thu, Sep 08, 2011 at 09:12:53PM -0000, Steve Atwell wrote:
> 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're right that this is not atomic; however, I believe the worst-case
scenario is that the kernel fs will be mounted twice at the same mount
point, which should not cause significant problems.  (I have seen this
outcome in practice on my machine while testing.)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org

-- 
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




More information about the foundations-bugs mailing list