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

[Brian J. Murrell]

On 11-07-01 02:52 PM, Forest wrote:
> Following up on my own question:  I don't see any updated mountall or
> nfs package in natty-proposed, and my fully-updated natty system still
> is still failing to mount my nfs shares at boot because of a race with
> statd.

My advise here would be either (a) give up on running a /var that's
separate from / and just learn to cope with a system that becomes
entirely useless at some point because something writing into /var has
filled your root filesystem or (b) switch to a different distro that
actually pays attention to "server deployment" practices wherein
separating /var from / (and /usr for that matter) is an accepted and
supported practice.

Given that this bug has existed since Lucid (3 releases now) makes it
clear to me that Ubuntu is not at all interested in supporting server
deployments where responsible practice is to keep /var from being able
to cripple an entire system simply because it fills up.

I guess Ubuntu is targeting the desktop and if you want to deploy
servers (where you likely will have budgets for support contracts) you
need to look at a different distro.

Just my perspective having watched this bug stagnate through three
releases.

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

Title:
  mountall for /var races with rpc.statd

Status in “mountall” package in Ubuntu:
  New
Status in “nfs-utils” package in Ubuntu:
  Fix Released
Status in “portmap” package in Ubuntu:
  Fix Released
Status in “mountall” source package in Lucid:
  New
Status in “nfs-utils” source package in Lucid:
  Fix Released
Status in “portmap” source package in Lucid:
  Fix Released
Status in “mountall” source package in Maverick:
  New
Status in “nfs-utils” source package in Maverick:
  Fix Released
Status in “portmap” source package in Maverick:
  Fix Released
Status in “mountall” source package in Natty:
  New
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/mountall/+bug/525154/+subscriptions