** 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
