[Bug 525154] Re: mountall for /var races with rpc.statd

[Clint Byrum]

Excerpts from Brian J. Murrell's message of Tue Jun 21 10:18:06 UTC 2011:
> On 11-06-20 07:10 PM, Clint Byrum wrote:
> > Christian, if you're using NFS root, you probably have an issue. But it
> > is probably not *this* issue, as this one was not specific to nfs root
> > configurations. It would be quite helpful if you were to raise a new bug
> > report against nfs-utils that detailed what you expect to have happen,
> > and what is actually happening.
> 
> But the question that begs to be asked is why are common configurations
> like NFS-root and separate /var and /usr filesystems STILL not part of
> Ubuntu's standard QA processes?
> 
> These are not entirely "esoteric" configurations you know and they have
> been shown to have problems in past releases so why are current QA
> processes not testing for these?
> 
> You do understand that effective QA means that when a configuration is
> shown to have a potential for regressions that such a configuration be
> added to the battery of tests that QA runs.  It's simply not effective
> to identify a configuration that doesn't work, (think that you have)
> fix(ed) it and simply move on and not ever test that configuration again
> during a regular release cycle.  That's exactly how regressions leak
> into GA product.  It's embarrassing.

Brian, much of our QA is still community driven. We devote significant
resources to testing the base system, but multi-server setups like NFS
root are taxing to manually test, and more complex to automate. I'd love
to say we write a regression test for every issue we fix and run it on
every possible configuration. Clearly, we don't.

If NFS root is important to you, I would suggest that you help us out
by gathering other interested users, and putting together a blueprint
for the next UDS. Lets get automated tests setup for this configuration.

I'd support this 100%, but I don't think we can do it without some help
from the actual users of NFS root systems.

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

Title:
  mountall for /var races with rpc.statd

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

Bug description:
  If one has /var (or /var/lib or /var/lib/nfs for that matter) on its
  own filesystem the statd.conf start races with the mounting of /var as
  rpc.statd needs /var/lib/nfs to be available in order to work.

  I am sure this is not the only occurrence of this type of problem.

  A knee-jerk solution is to simply spin in statd.conf waiting for
  /var/lib/nfs to be available, but polling sucks, especially for
  something like upstart whose whole purpose is to be an event driven
  action manager.

  SRU justification: NFS mounts do not start reliably on boot in lucid
  and maverick (depending on the filesystem layout of the client system)
  due to race conditions in the startup of statd.  This should be fixed
  so users of the latest LTS can make reliable use of NFS.

  Regression potential:  Some systems may fail to mount NFS filesystems
  at boot time that didn't fail before.  Some systems may hang at boot.
  Some systems may hang while upgrading the packages (this version or in
  a future SRU).  I believe the natty update adequately guards against
  all of these possibilities, but the risk is there.

  TEST CASE:
  1. Configure a system with /var as a separate partition.
  2. Add one or more mounts of type 'nfs' to /etc/fstab.
  3. Boot the system.
  4. Verify whether statd has started (status statd) and whether all NFS filesystems have been mounted.
  5. Repeat 3-4 until the race condition is triggered.
  6. Upgrade to the new version of portmap and nfs-common from -proposed.
  7. Repeat steps 3-4 until satisfied that statd now starts reliably and all non-gss-authenticated NFSv3 filesystems mount correctly at boot time.

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