[Bug 610863] Re: Race condition in statd.conf
I just noticed that the underlying upstart issue mentioned in #8 is already described by https://bugs.launchpad.net/upstart/+bug/530779. I won't mark this as a duplicate though - the workaround described here may be useful until the upstart bug is fixed. -- Race condition in statd.conf https://bugs.launchpad.net/bugs/610863 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
Tested on Maverick alpha 3 and confirmed that this bug is still present. Debdiff for Maverick attached. ** Patch added: nfs-utils_1.2.2-1ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/610863/+attachment/1497666/+files/nfs-utils_1.2.2-1ubuntu2.debdiff -- Race condition in statd.conf https://bugs.launchpad.net/bugs/610863 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
apport information ** Tags added: apport-collected ** Description changed: Binary package hint: mountall On my Lucid system with latest updates, NFS filesystems sometimes fail to mount successfully at boot. After a boot where the NFS mounts fail, the mountall process is still running when I log in. Running kill -USR1 $(pidof mountall) will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 mountall version: 2.15 + --- + Architecture: i386 + DistroRelease: Ubuntu 10.04 + InstallationMedia: Mythbuntu 10.04 LTS Lucid Lynx - Release i386 (20100427.1) + NonfreeKernelModules: nvidia + Package: nfs-common 1:1.2.0-4ubuntu4 + PackageArchitecture: i386 + ProcEnviron: + SHELL=/bin/bash + LANG=en_AU.UTF-8 + ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5 + Tags: lucid + Uname: Linux 2.6.32-23-generic-pae i686 + UserGroups: ** Attachment added: Dependencies.txt https://bugs.edge.launchpad.net/bugs/610863/+attachment/1493220/+files/Dependencies.txt -- Race condition in statd.conf https://bugs.launchpad.net/bugs/610863 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
** Description changed: - Binary package hint: mountall + Binary package hint: nfs-common + nfs-common version: 1:1.2.0-4ubuntu4 - On my Lucid system with latest updates, NFS filesystems sometimes fail to mount successfully at boot. After a boot where the NFS mounts fail, the mountall process is still running when I log in. Running kill -USR1 $(pidof mountall) will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: + On my Lucid system with latest updates, NFS filesystems sometimes fail + to mount successfully at boot. + + Steps to reproduce: + 1. In /etc/fstab, add an entry of the form: + nfs-server:sharemountpointnfs_netdev 0 0 + 2. Reboot a number of times + + Expected results: + The NFS filesystem should be mounted on every boot + + Actual results: + Occasionally the NFS mount fails and messages of the following form are logged in /var/log/boot.log: + mount.nfs: rpc.statd is not running but is required for remote locking. + mount.nfs: Either use '-o nolock' to keep locks local, or start statd. + mountall: mount mountpoint [pid] terminated with status 32 + + After a boot where the NFS mounts fail, the mountall process is still running on login. Running: + kill -USR1 $(pidof mountall) + will then mount the missing filesystems sucessfully. + + It is also possible to observe the problem without rebooting as follows. + + Steps to reproduce: + Run the following shell loop, after setting $nfs_server, $share and $mntpt to suitable values + + i=0 + while (( i 100 )) + do + stop statd + start statd + mount.nfs $nfs_server:$share $mntpt + umount $mntpt + (( i++ )) + done + + Expected results: + The NFS filesystem should be mounted on every iteration of the loop + + Actual results: + Occasionally the NFS mount fails and the following messages are output: + + mount.nfs: rpc.statd is not running but is required for remote locking. + mount.nfs: Either use '-o nolock' to keep locks local, or start statd. + mount.nfs: an incorrect mount option was specified + umount: mountpoint not mounted + + The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 - mountall version: 2.15 - --- + --- Architecture: i386 DistroRelease: Ubuntu 10.04 InstallationMedia: Mythbuntu 10.04 LTS Lucid Lynx - Release i386 (20100427.1) NonfreeKernelModules: nvidia Package: nfs-common 1:1.2.0-4ubuntu4 PackageArchitecture: i386 ProcEnviron: - SHELL=/bin/bash - LANG=en_AU.UTF-8 + SHELL=/bin/bash + LANG=en_AU.UTF-8 ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5 Tags: lucid Uname: Linux 2.6.32-23-generic-pae i686 UserGroups: -- Race condition in statd.conf https://bugs.launchpad.net/bugs/610863 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
The above patch adds a post-start script that loops until the statd parent process has exited. This is the best workaround that I can think of. It doesn't seem possible to just wait() for the process with the current implementation of upstart's expect fork feature. Suggestion for a better approach: The start script should be allowed to tell upstart the PID of the process that upstart should supervise. The information could be sent (for example) via a pipe, or the traditional /var/run/job.pid file. Then the knowledge of how to correctly start a particular daemon could be entirely in the start script where it belongs, rather than part of it being coded into upstart. This would allow the expect fork and expect daemon features to go away. -- Race condition in statd.conf https://bugs.launchpad.net/bugs/610863 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
** Tags added: patch -- Race condition in statd.conf https://bugs.launchpad.net/bugs/610863 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
