Created attachment 365024 [details] journalctl: NFS fstab mount BEFORE rpc-statd 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 sys-apps/systemd-208-r2:0/1 net-fs/nfs-utils-1.2.9 Symptoms: - systemd cannot mount an NFS share from /etc/fstab during during booting (which used to be mounted without a problem under OpenRC). But if later I run 'systemctl start sharename.mount' the share mount well. OS: - Gentoo and ArchLinux (exactly the same behaviour) What I've gathered: journalctl shows that systemd tries to bring up remote-fs.target and all its dependencies (including the NFS share) BEFORE it proceeds to starting up rpc-statd daemon. I examined /usr/lib/systemd/system/rpc-statd.target file and learnt that there was 'Before=remote-fs-pre.target' but no 'Wants=remote-fs-pre.target'. And 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. I added this line to /usr/lib/systemd/system/rpc-statd.target and got the correct order of starting (i.e. the share got mounted after rpc-statd had completed launching). I've attached the full journalctl output for one boot sequence. The share name is '/sugar'
Here's Fedora's unit, for reference. http://pkgs.fedoraproject.org/cgit/nfs-utils.git/tree/nfs-lock.service
It has "Before" instead of "Wants" on fedora :/
Why, I've tried the same on Fedora. 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 After reboot, to my surprise, the share got connected. BUT! Afterwards I examined journalctl (in the attachment) and found that the launch order was not correct all the same. 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 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 on Fedora. I believe I need to file a bug for them as well.
Created attachment 365082 [details] The similar sequence on Fedora
(In reply to Pacho Ramos from comment #2) > It has "Before" instead of "Wants" on fedora :/ I suppose there must be both - "Before" and "Wants".
+*nfs-utils-1.2.9-r1 (22 Dec 2013) + + 22 Dec 2013; Pacho Ramos <pacho@gentoo.org> +files/rpc-statd.service-r1, + +nfs-utils-1.2.9-r1.ebuild: + Wants=remote-fs-pre.target is needed (#493798 by Vitaly Kirsanov) +
