Bug 773078 - NFS mounts not always mounted at boot
NFS mounts not always mounted at boot
Status: CLOSED DUPLICATE of bug 786050
Product: Fedora
Classification: Fedora
Component: nfoview (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-01-10 16:04 EST by Rasmus Ory Nielsen
Modified: 2012-03-19 10:11 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-19 10:11:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg with systemd logging enabled (/mgsraw failed this time) (155.42 KB, text/plain)
2012-01-10 16:09 EST, Rasmus Ory Nielsen
no flags Details

  None (edit)
Description Rasmus Ory Nielsen 2012-01-10 16:04:16 EST
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


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
Comment 1 Rasmus Ory Nielsen 2012-01-10 16:09:04 EST
Created attachment 551935 [details]
dmesg with systemd logging enabled (/mgsraw failed this time)
Comment 2 Michal Schmidt 2012-03-18 11:04:55 EDT
[   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:
Comment 3 Rasmus Ory Nielsen 2012-03-18 15:22:21 EDT
Thanks, I will do some testing, stay tuned
Comment 4 Rasmus Ory Nielsen 2012-03-19 04:58:05 EDT
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

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.

Comment 5 Rasmus Ory Nielsen 2012-03-19 05:06:20 EDT
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.
Comment 6 Steve Dickson 2012-03-19 08:07:12 EDT
(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?

Comment 7 Rasmus Ory Nielsen 2012-03-19 09:20:52 EDT
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?

Comment 8 Michal Schmidt 2012-03-19 10:11:29 EDT
It could be explained by the fixing of bug 786050.

*** This bug has been marked as a duplicate of bug 786050 ***

Note You need to log in before you can comment on or make changes to this bug.