[Bug 1037192] Re: NFS shares are mounted with wrong clientaddr or not at all

[Nick Hatch]

I can confirm this problem on Precise 12.04.3 with mountall=2.36.4 from
precise-updates.

With clientaddr=0.0.0.0, nfsstat -s showed rapidly incrementing
'setcltid' and 'setcltidconf' operations on the server, and high IO
utilization on the root volume due to writing v4recovery information.

Although I am not certain on this part, shortly after performing updates
on three clients which bumped mountall to 2.36.4, our NFS server crashed
after 300 days of uptime less than 24 hours later. ( Don't have much
data here, but it was brought down due to an OOM condition, I'm assuming
due to a memory leak somewhere in the NFS code. This server is used
exclusively for NFS, and no user-land process was to blame. )

Reverting mountall to 2.36 and rebooting restored a properly configured
clientaddr, and the excessive client ID operations stopped.

Changes in mountall 2.36.1 and 2.36.2 both seem highly suspicious, see
LP #643289 and LP #1078926.

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

Title:
  NFS shares are mounted with wrong clientaddr or not at all

Status in “mountall” package in Ubuntu:
  Confirmed

Bug description:
  With the following fstab:

  proc /proc proc nodev,noexec,nosuid 0 0
  /dev/mapper/vg0-fat_client / ext4 relatime,errors=remount-ro 0 1
  /dev/mapper/vg0-swap none swap sw 0 0
  spitzer:/opt /opt nfs4 auto 0 0
  spitzer:/home /home nfs4 auto 0 0

  The  /opt and /home are sometimes not mounted at all, and sometimes
  with the wrong clientaddr:

  $ mount | grep nfs
  rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
  spitzer:/home on /home type nfs4 (rw,clientaddr=0.0.0.0,addr=192.168.1.2)
  spitzer:/opt on /opt type nfs4 (rw,clientaddr=0.0.0.0,addr=192.168.1.2)

  Since this happens on all clients (they all get same clientaddr), this
  results in a frozen mount (cf
  http://thread.gmane.org/gmane.linux.nfs/47780)

  The "spitzer" host is only reachable via a tinc VPN, and mounting (or
  remounting) manually after boot always works and results in the
  correct clientaddr, so I believe that mountall is attempting to mount
  this too early.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: mountall 2.15.3
  ProcVersionSignature: Ubuntu 3.0.0-23.39~lucid1-server 3.0.36
  Uname: Linux 3.0.0-23-server x86_64
  Architecture: amd64
  Date: Wed Aug 15 12:16:17 2012
  ProcEnviron:
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: mountall

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1037192/+subscriptions