Created attachment 840723 [details]
The output of journalctl

Description of problem:

Shortly, NFS file systems are mounted before nfs-lock service is started. 

Below is the example of a start-up sequence. The NFS share name is /sugar


I made a brand-new Fedora installation on a virtual machine (with nfs-utils 1.2.8-6.0) and then ran the following commands:

systemctl enable nfs-lock.service
systemctl enable nfs.target
systemctl enable remote-fs.target

and also added the following line to /etc/fstab

192.168.1.254:/mnt/HD/HD_a2 /sugar nfs defaults 0 0

The share got connected.

BUT!

Afterwards I examined journalctl (in the attachment) and found that the launch order was not correct. Here are the key moments of the booting:

Dec 11 00:35:46 localhost.localdomain systemd[1]: Starting Network.
Dec 11 00:35:46 localhost.localdomain systemd[1]: Reached target Network.
Dec 11 00:35:46 localhost.localdomain systemd[1]: Starting RPC bind service...
Dec 11 00:35:46 localhost.localdomain systemd[1]: Mounting /sugar...
Dec 11 00:35:47 localhost.localdomain systemd[1]: Started RPC bind service.
Dec 11 00:35:47 localhost.localdomain systemd[1]: Starting NFS file locking service....
Dec 11 00:35:48 localhost.localdomain rpc.statd[993]: Version 1.2.7 starting
Dec 11 00:35:48 localhost.localdomain rpc.statd[993]: Flags: TI-RPC
Dec 11 00:35:48 localhost.localdomain sm-notify[979]: Version 1.2.7 starting
Dec 11 00:35:48 localhost.localdomain rpc.statd[993]: Initializing NSM state
Dec 11 00:35:49 localhost.localdomain rpc.statd[978]: Failed to rename /var/lib/nfs/statd/state.new -> /var/lib/nfs/statd/state: No such file or directory
Dec 11 00:35:49 localhost.localdomain systemd[1]: nfs-lock.service: control process exited, code=exited status=1
Dec 11 00:35:49 localhost.localdomain systemd[1]: Failed to start NFS file locking service..
Dec 11 00:35:49 localhost.localdomain systemd[1]: Unit nfs-lock.service entered failed state.
Dec 11 00:35:49 localhost.localdomain systemd[1]: Starting Network File System Server.
Dec 11 00:35:49 localhost.localdomain systemd[1]: Reached target Network File System Server.
Dec 11 00:35:49 localhost.localdomain systemd[1]: Mounted /sugar.
Dec 11 00:35:49 localhost.localdomain systemd[1]: Starting Remote File Systems.
Dec 11 00:35:49 localhost.localdomain systemd[1]: Reached target Remote File Systems.

The full log is attached to the report.

The normal sequence would be Network -> RPC bind -> NFS lock -> Remote File Systems (Pre) -> mount /sugar -> Remote File Systems

But here you can see that systemd started mounting /sugar in parallel with launch of RPC bind service. I suppose the mounting ended successfully because at the moment /sugar started to be mounted RPC bind had already started (although the report came later) and that was sufficient for 'mount' command to automatically launch rpc-statd.

Moreover nfs-lock service was started AFTER mounting /sugar.

And I ran this command after booting

[root@localhost ~]# systemctl status remote-fs-pre.target
remote-fs-pre.target - Remote File Systems (Pre)
   Loaded: loaded (/usr/lib/systemd/system/remote-fs-pre.target; static)
   Active: inactive (dead)
     Docs: man:systemd.special(7)

[root@localhost ~]#

This suggests that nobody pulled in remote-fs-pre.target which would have guaranteed the correct and safest order of execution.

So I think it's only by chance that it may work.







Version-Release number of selected component (if applicable):

nfs-utils-1:1.2.8-6.0.fc19 (64 bit)








How reproducible:

always






Steps to Reproduce:

See above.






Actual results:


Expected results:


Additional info:

Initially the problem was found in Gentoo and ArchLinux distributions but later it turned out that the problem came from Fedora. Please see the link on the Gentoo's bug.