** Description changed: - Binary package hint: upstart - If one has /var (or /var/lib or /var/lib/nfs for that matter) on its own filesystem the statd.conf start races with the mounting of /var as rpc.statd needs /var/lib/nfs to be available in order to work. I am sure this is not the only occurrence of this type of problem. A knee-jerk solution is to simply spin in statd.conf waiting for /var/lib/nfs to be available, but polling sucks, especially for something like upstart whose whole purpose is to be an event driven action manager. + + SRU justification: NFS mounts do not start reliably on boot in lucid and + maverick (depending on the filesystem layout of the client system) due + to race conditions in the startup of statd. This should be fixed so + users of the latest LTS can make reliable use of NFS. + + Regression potential: Some systems may fail to mount NFS filesystems at + boot time that didn't fail before. Some systems may hang at boot. Some + systems may hang while upgrading the packages (this version or in a + future SRU). I believe the natty update adequately guards against all + of these possibilities, but the risk is there. + + TEST CASE: + 1. Configure a system with /var as a separate partition. + 2. Add one or more mounts of type 'nfs' to /etc/fstab. + 3. Boot the system. + 4. Verify whether statd has started (status statd) and whether all NFS filesystems have been mounted. + 5. Repeat 3-4 until the race condition is triggered. + 6. Upgrade to the new version of portmap and nfs-common from -proposed. + 7. Repeat steps 3-4 until satisfied that statd now starts reliably and all non-gss-authenticated NFSv3 filesystems mount correctly at boot time.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/525154 Title: mountall for /var races with rpc.statd -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
