Bug 740502 - NFS filesystems are not mounted during boot
NFS filesystems are not mounted during boot
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-22 05:22 EDT by Vít Ondruch
Modified: 2011-11-18 11:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-18 11:09:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vít Ondruch 2011-09-22 05:22:07 EDT
Description of problem:
I am trying to mount some NFS shares during boot. However it doesn't work properly.

Version-Release number of selected component (if applicable):
# rpm -q nfs-utils
nfs-utils-1.2.4-8.fc16.x86_64

How reproducible:
Always

Steps to Reproduce:
1. # cat /etc/fstab | grep nfs
filer-eng.brq.redhat.com:/vol/mirrors/engineering  /mnt/mirror        nfs ro,noauto,comment=systemd.automount  0 0
2. # LANG=C ls /mnt
ls: cannot access /mnt/mirror: No such device
3. # mount /mnt/mirror
mount.nfs: No such device
4. # mount filer-eng.brq.redhat.com:/vol/mirrors/engineering /mnt/foo
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
  
Actual results:
The mount is not mounted. It cannot be remounted, unmounted, anything. It is quite hard to find wht the prc.statd actually is, so the message is confusing, although the '-o nolock' option seems to work.

I also take look and see that there is supposed to run the nfs-lock.service but it failed for some reason:

# systemctl status nfs-lock.service 
nfs-lock.service - NFS file locking service.
	  Loaded: loaded (/lib/systemd/system/nfs-lock.service; enabled)
	  Active: failed since Thu, 22 Sep 2011 08:02:25 +0200; 3h 17min ago
	 Process: 1447 ExecStart=/sbin/rpc.statd $STATDARG (code=exited, status=1/FAILURE)
	 Process: 1434 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/nfs-lock.service

So that is probably main reason for my issues.

Expected results:
NFS mount should be mounted after start.
Comment 1 Jon Disnard 2011-10-31 11:19:19 EDT
Same problem. NFS shares for user home dirs specified in autofs maps. Uses unable to login after bootup.

It seems the nfs-lockd.service is running, but has the same problem described by Vít Ondruch. I was able to work-around the issue by stoppign at starting the service. Please note, simply restarting the service fails to work. Also, even though systemctl status indicates the service inoperable (and that is true) the PID file exists in /var/run/rpc.statd.pid, and the process was alive.

So the process had to be killed, and a new process created.


# systemctl stop nfs-lock.service

# systemctl start nfs-lock.service


# systemctl status nfs-lock.service
nfs-lock.service - NFS file locking service.
          Loaded: loaded (/lib/systemd/system/nfs-lock.service; enabled)
          Active: active (running) since Sun, 30 Oct 2011 22:22:28 -0500; 6s ago
         Process: 26125 ExecStopPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0 fs.nfs.nlm_udpport=0 (code=exited, status=0/SUCCESS)
         Process: 26162 ExecStart=/sbin/rpc.statd $STATDARG (code=exited, status=0/SUCCESS)
         Process: 26158 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig (code=exited, status=0/SUCCESS)
        Main PID: 26164 (rpc.statd)
          CGroup: name=systemd:/system/nfs-lock.service
                  â 26164 /sbin/rpc.statd



This should work on bootup.
Comment 2 Steve Dickson 2011-11-14 10:28:04 EST
(In reply to comment #1)
> Same problem. NFS shares for user home dirs specified in autofs maps. Uses
> unable to login after bootup.
> 
> It seems the nfs-lockd.service is running, but has the same problem described
> by Vít Ondruch. I was able to work-around the issue by stoppign at starting the
> service. Please note, simply restarting the service fails to work. Also, even
> though systemctl status indicates the service inoperable (and that is true) the
> PID file exists in /var/run/rpc.statd.pid, and the process was alive.
> 
> So the process had to be killed, and a new process created.

Where there any type of failures logged in /var/log/messages?
Comment 3 Jon Disnard 2011-11-16 02:06:46 EST
(In reply to comment #2)
[snip]
> 
> Where there any type of failures logged in /var/log/messages?

I do not believe there were any syslogs related to the nfs-lockd at the time I reported in comment #1. The output of systemctl was the only clear indication of the problem statement. Also please note the process was there, the pid file existed. However the process didn't work, and  systemctl said the start of the service failed. 

There is some good news.
The issue seems to have gone away.

What has changed?

* the aforementioned systemctl stop/start nfs-lockd.service.

* The system was not reset  since the initial report.

* To assist with the bugzilla the system was reset to have the issue reproduce.

* yum update


I was hoping Vít might try to reproduce my success with the systemctl stop/start of nfs-lockd.
Comment 4 Steve Dickson 2011-11-18 11:09:02 EST
(In reply to comment #3)
> (In reply to comment #2)
> [snip]
> > 
> > Where there any type of failures logged in /var/log/messages?
> 
> I do not believe there were any syslogs related to the nfs-lockd at the time I
> reported in comment #1. The output of systemctl was the only clear indication
> of the problem statement. Also please note the process was there, the pid file
> existed. However the process didn't work, and  systemctl said the start of the
> service failed. 
> 
> There is some good news.
> The issue seems to have gone away.
> 
> What has changed?
> 
> * the aforementioned systemctl stop/start nfs-lockd.service.
No... There is an upcoming change to ensure the network is
up before the service is started... 
> 
> * The system was not reset  since the initial report.
This could be it..

> 
> * To assist with the bugzilla the system was reset to have the issue reproduce.
Rebooting sometime does do magically things! 8-)

> 
> * yum update
This is always a good option... especially with an early release
of a new version of Fedora... 

> 
> I was hoping Vít might try to reproduce my success with the systemctl
> stop/start of nfs-lockd.
Make my Day! ;-)

At this point I'm going to close the bug as fixed... Please feel free 
to reopen if the problem comes back...

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