Arch Linux

Description:

Shortly, NFS file systems are mounted before nfs-statd and rpcbind services have started.

At first I created a bug report at bugzilla.linux-nfs.org but I was told the problem may be introduced by the distributor. Here is the link to the bug

https://bugzilla.linux-nfs.org/show_bug.cgi?id=237



Initially I found this bug in Gentoo (https://bugs.gentoo.org/show_bug.cgi?id=493798) but then double-checked in ArchLinux and the behaviour was exactly the same. Then it turned out that the problem came (at least for Gentoo) from Fedora distribution (https://bugzilla.redhat.com/show_bug.cgi?id=1046015)



Symptoms:

systemd cannot mount an NFS share from /etc/fstab during booting. But if later I run 'systemctl start sharename.mount' the share mounts well.


The NFS-mount name is /sugar

I ran the following commands

systemctl enable nfs-statd.service
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

This is the key moments of journalctl output after rebooting.

дек. 04 00:59:38 squirrel systemd[1]: Reached target Network.
дек. 04 00:59:38 squirrel systemd[1]: Starting RPC Bind...
дек. 04 00:59:38 squirrel systemd[1]: Mounting /sugar...
дек. 04 00:59:38 squirrel mount[2187]: mount.nfs: mount system call failed
дек. 04 00:59:38 squirrel systemd[1]: sugar.mount mount process exited, code=exited status=32
дек. 04 00:59:38 squirrel systemd[1]: Unit sugar.mount entered failed state.
дек. 04 00:59:38 squirrel systemd[1]: Started RPC Bind.
дек. 04 00:59:38 squirrel systemd[1]: Starting RPC Port Mapper.
дек. 04 00:59:38 squirrel systemd[1]: Reached target RPC Port Mapper.
дек. 04 00:59:38 squirrel systemd[1]: Starting NFSv2/3 Network Status Monitor Daemon...
дек. 04 00:59:38 squirrel rpc.statd[2201]: Version 1.2.7 starting
дек. 04 00:59:38 squirrel rpc.statd[2201]: Running as root. chown /var/lib/nfs to choose different user
дек. 04 00:59:38 squirrel systemd[1]: Started NFSv2/3 Network Status Monitor Daemon.

The normal sequence would be Network -> rpcbind -> rpc-statd -> 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. Moreover nfs-statd 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.

systemd.special(7) manual says that remote-fs-pre.target is a passive target and must be pulled in by the provider rather than the consumer of the target.

Additional info:
* package version(s)
nfs-utils 1.2.9-1

* config and/or log files etc.


Steps to reproduce: