[Bug 643289] Re: idmapd does not starts to work after system reboot

[Sergey Pashinin]

I had this crazy problem with NFS and not started idmapd after reboot on my Ubuntu 12.10 x64.
I tested a lot of advices from the internet but found my crazy soltion. I don't know why it works :)

I used to have in my fstab:
10.254.239.1:/usr/data/disk_1   /usr/data/disk_1         nfs4   _netdev,rsize=8192,wsize=8192,timeo=1,soft,retry=0,auto,bg  0 0

The only thing I changed was ip address:
domain.com:/usr/data/disk_1   /usr/data/disk_1         nfs4   _netdev,rsize=8192,wsize=8192,timeo=1,soft,retry=0,auto,bg  0 0

Actually domain.com resolves to 10.254.239.1 (My DNS server is on 10.254.239.1 also)
But there are even errors "Can't be resolved" in log. So I don't know why it works.

But still it mounts(!) now and everything is working.
I hope that it will help somebody and hope will never see such bugs again

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

Title:
  idmapd does not starts to work after system reboot

Status in “mountall” package in Ubuntu:
  Fix Released
Status in “nfs-utils” package in Ubuntu:
  Fix Released
Status in “mountall” source package in Lucid:
  Won't Fix
Status in “nfs-utils” source package in Lucid:
  Won't Fix
Status in “mountall” source package in Precise:
  Fix Committed
Status in “nfs-utils” source package in Precise:
  Triaged

Bug description:
  [Impact]
  Certain systems which make extensive use of NFS mounts have not been able to boot reliably since the migration to mountall in Ubuntu 9.10.  This is because of race conditions in the handling of mounts vs. the startup of NFS client daemons.  A proper fix of the startup of the NFS client daemons would in turn cause a deadlock of mountall, which processes mounts serially.  We should fix mountall to parallelize its handling of mounts, so that the NFS daemons can be fixed properly.
  This issue also impacts the cloud-init package, which relies on being able to do 'start on mounted MOUNTPOINT=/' and the like.

  [Test case]
  1. Have Scott Moser confirm that the package in -proposed resolves the 120-second boot-time delay in cloud images when using cloud-init.

  [Regression potential]
  Difficult to quantify.  This code was included in the 12.10 release, however a regression was found in that code (bug #1059471) which is now being fixed there in SRU.  There may be other latent regressions that have not yet been identified.  Furthermore, introducing additional asynchronous handling here has the potential to expose race conditions (bugs) in other code that currently works by accident due to the serial handling of mounts.

  Binary package hint: nfs-common

  I have server which runs Kerberos+LDAP+NFSv4. After installing minimal Ununtu 10.10, I set up Kerberos client and NFSv4. But I've got a problem when restarted computer. After some retries I've noticed that idmapd does not work properly after system restarts but there is a workaround which makes it work:
  1. Edit /etc/rc.local and place there following commands
  sleep 5
  service autofs stop
  service idmapd restart
  service autofs start
  2. Add rc.local to system startup:
  update-rc.d rc.local enable

  Hope this workaround will help to find out the source of the problem.
  It is obvious that something launches in wrong way. But what is that?

  Thanks!

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