[Bug 525154] Re: mountall for /var or other nfs mount races with rpc.statd

[Oliver Brakmann]

Hi,

this is turning into a forum discussion real fast, and really has no
place here.  I suggest we take it someplace else. Ubuntu-devel, maybe?

On 2011-07-19 12:17, Brian J. Murrell wrote:
> On 11-07-18 04:27 PM, Steve Langasek wrote:
>>
>> This appears to be bug #523484.
>> To the best of my understanding, this describes a feature that is missing
> Uhm, not so much "missing" as "broken".
>> when using a separate /var (the ureadahead job will run but not do anything
>> useful).
> 
> It's not even that nice.  What it will do is litter the boot with error
> messages

I think "litter" is a bit strong.  There's a single line that says that
ureadahead terminated with status soandso.  That's hardly littering.
And that's about it with regard to the impact of that bug.  I have never
seen a system not boot due to it, and I have used (and am using) Lucid
on bare-metal servers, virtual machines, desktops and road warrior
laptops, all with a separate /var.

> which is annoying and distracting at best and a red herring
> when there are other upstart/mountall bugs, at worst.

I'll agree that it is annoying, but any admin that sees the ureadahead
message when a system shows other problems and goes 'oh, ureadahead
croaked, that must be the cause of it all!' seriously needs to drop it
right then and there and go stack shelves somewhere.

>> This is certainly a bug, but not something that we are likely to
>> backport to lucid even when a fix becomes available.
> 
> So instead you let the above situation continue on ad infinitum,
> confusing new users?

That's not what Steve said.

>> I think you would be
>> hard pressed to convince any of the Ubuntu developers that it has a major
>> impact on the usability of Ubuntu that systems with a separate /var don't
>> get the boot speed enhancement from ureadahead!

I agree.

> Exactly my point and the point of mine (and others') frustration.  You
> guys let a bug get out into the wild by not testing a use-case that is
> and/or should be very common in the server use space and now that it's
> out there, you are just letting it ride.

Again, I agree that the message is annoying, and it would be nice if we
could get rid of it.  But I would describe it as 'cosmetic' at best, and
hardly something to get frustrated about, much less fault the developers
for not giving it highest priority.

So is this seriously something to get so worked up about?

Also, you know, Ubuntu makes alphas public for a reason.


Regards,
Oliver

-- 
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 or other nfs mount races with rpc.statd

Status in “mountall” package in Ubuntu:
  Invalid
Status in “nfs-utils” package in Ubuntu:
  Fix Released
Status in “portmap” package in Ubuntu:
  Fix Released
Status in “mountall” source package in Lucid:
  Invalid
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:
  Invalid
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:
  Invalid
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