Bug 1046015
Summary: | nfs-lock.service should set Wants=remote-fs-pre.target | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vitaly Kirsanov <krokoziabla> | ||||
Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 19 | CC: | bfields, steved | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-12-13 19:33:38 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
This is now done by nfs-client.target |
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.