** Description changed:

+ [Impact]
+ 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!

** Description changed:

  [Impact]
- 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.
+ 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!

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

Title:
  idmapd does not starts to work after system reboot

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to