Red Hat Bugzilla – Bug 773078
NFS mounts not always mounted at boot
Last modified: 2012-03-19 10:11:29 EDT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7 NFS mounts are not always mounted after booting. The machine has 4 nfs mounts. Most of the time all 4 are mounted at boot, but once in a while one (or more) of the 4 are not mounted after boot. It varies which one is missing. As a side note, the same setup works for the rest of our cluster (running f13). Reproducible: Sometimes Steps to Reproduce: 1. Clean f16 kickstart install, apply updates, old-style network service, static ip, selinux disabled, 4 nfs mounts 2. Verify mount points work 3. Reboot Actual Results: After rebooting, the 4 nfs mounts are mounted most of the time. But once in a while (maybe every 4 reboot) one of the mount points are not mounted. More seldom two or more mount points are missing. It is not always the same mount point thats missing. Mounting manually after logging in works fine. Expected Results: All nfs mounts defined in /etc/fstab should be mounted at boot systemd-37-3.fc16.x86_64 The relevant entries from /etc/fstab: filer:/vol/new_v1mgs /mgs nfs vers=3,noatime,rw,tcp 0 0 filer:/vol/v2home /home nfs vers=3,noatime,rw,tcp 0 0 filer:/vol/v10mgsdata /mgsraw nfs vers=3,noatime,ro,tcp 0 0 filer:/vol/v11mgs_data /mgs/data nfs vers=3,noatime,rw,tcp 0 0 # systemctl status mgsraw.mount mgsraw.mount - /mgsraw Loaded: loaded Active: failed since Tue, 10 Jan 2012 14:34:08 +0100; 7h ago Where: /mgsraw What: filer:/vol/v10mgsdata Process: 1083 ExecMount=/bin/mount /mgsraw (code=exited, status=32) CGroup: name=systemd:/system/mgsraw.mount └ 1119 rpc.statd --no-notify
Created attachment 551935 [details] dmesg with systemd logging enabled (/mgsraw failed this time)
[ 49.653334] systemd[1]: Received SIGCHLD from PID 1123 (rpc.statd). [ 49.653371] systemd[1]: Got SIGCHLD for process 1123 (rpc.statd) [ 49.653445] systemd[1]: Child 1123 died (code=exited, status=1/FAILURE) [ 49.664238] FS-Cache: Loaded [ 49.686584] FS-Cache: Netfs 'nfs' registered for caching [ 49.687988] mount[1083]: mount.nfs: No such device [ 49.688272] systemd[1]: Received SIGCHLD from PID 1083 (mount). [ 49.688305] systemd[1]: Got SIGCHLD for process 1083 (mount) [ 49.688369] systemd[1]: Child 1083 died (code=exited, status=32/n/a) [ 49.688375] systemd[1]: Child 1083 belongs to mgsraw.mount I don't know the reason of these failures, but it looks like it has more to do with nfs-utils than systemd itself. Reassigning. Maybe it is fixed by: https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-5.fc16
Thanks, I will do some testing, stay tuned
Good news! I have been doing some tests, and the problem seems to have gone away. However, I can not tell which update that made the difference. Because, since submitting the bug report, I haven't paid attention to the problem. Instead I just added a cron @reboot statement to make sure all nfs mounts were active. But, even though my tests shows, that with a fully updated system all nfs mount points works, there's still a little quirk - some or all of the mount points are not mounted immediately. Those missing will appear exactly 60 seconds after reboot (systemd-analyze blame confirms this). Luckily the nfs-utils-1.2.5-5 update fixes this problem! I will do some more testing, but for now it certainly looks this this bug has been squashed. Thanks
I forgot to add, that after installing the nfs-utils update, 'systemd-analyze blame' shows initialization times for the nfs mount points in the range 20-50ms.
(In reply to comment #5) > I forgot to add, that after installing the nfs-utils update, 'systemd-analyze > blame' shows initialization times for the nfs mount points in the range > 20-50ms. Is this good or bad? Also can we close out this bz? tia..
Sorry for being unclear. 20-50ms is good, compared to before the nfs-utils update, where it often took about about 60000ms. I think we can close this bz. What's the correct status: closed/currentrelease? Thanks.
It could be explained by the fixing of bug 786050. *** This bug has been marked as a duplicate of bug 786050 ***