Bug 786050 - insufficient ordering of NFS-related units
insufficient ordering of NFS-related units
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
16
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
: 773078 798234 799990 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-31 04:35 EST by Blakkheim.GW
Modified: 2012-05-08 00:11 EDT (History)
13 users (show)

See Also:
Fixed In Version: nfs-utils-1.2.5-14.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-23 20:26:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Output of dmesg (200.26 KB, text/plain)
2012-01-31 05:07 EST, Blakkheim.GW
no flags Details
Output of dmesg (201.07 KB, text/plain)
2012-02-01 02:36 EST, Blakkheim.GW
no flags Details

  None (edit)
Description Blakkheim.GW 2012-01-31 04:35:43 EST
Description of problem: After upgrading systemd, systemd-sysv and sytemd-units, NFS mounts are not mounted at boot time. All units <name>.mount are in failed state.


Version-Release number of selected component (if applicable): 37-11.fc16.x86_64


How reproducible: add a NFS mount in /etc/fstab and try to boot with systemd-37-11. Mount points are empty and sytemd units are in failed state. Downgrading to previous version of systemd resolve the problem.
Comment 1 Michal Schmidt 2012-01-31 04:44:15 EST
Please boot with the kernel command line arguments "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" and then attach the output of the dmesg command.
Comment 2 Blakkheim.GW 2012-01-31 05:07:26 EST
Created attachment 558585 [details]
Output of dmesg
Comment 3 Blakkheim.GW 2012-01-31 05:07:44 EST
I just saw this in /var/log/messages :

mount.nfs: Failed to resolve server <servername>: Name or service not known

We had this issue previously because netfs mounts were started too early after NetworkManager. Recently we had the issue again after a nfs-utils upgrade (it has been corrected a few weeks ago).

I attached dmesg output.
Comment 4 Michal Schmidt 2012-01-31 05:20:26 EST
You use NetworkManager (as opposed to network.service), require synchronization on the network connection being up, but don't have NetworkManager-wait-online.service enabled. See if enabling it helps.
Comment 5 Blakkheim.GW 2012-01-31 06:01:17 EST
When I encountered previous issues with NFS mounts, I tried to enable this service but it broke the ypbind connection.

I've juste enabled the service and rebooted serveral times : NFS shares are correctly mounted and ypbind has no more problems. Boot time is significantly longer though, blocking several dozens of seconds starting NIS services..
Comment 6 Michal Schmidt 2012-01-31 07:13:10 EST
To find out what unit takes long to start, you can use:
systemd-analyze blame
systemd-analyze plot > sa.svg
... or again the dmesg output with debugging enabled.
Comment 7 Blakkheim.GW 2012-01-31 09:56:41 EST
Outpout of the first command point out that this is mount units that take forever to complete.

Complete bootup process take 120 seconds...

Before the systemd update, the bootup process took approximately 30-40 seconds (with no NetworkManager-wait-online.service enabled) and NFS shares were mounted.
Comment 8 Michal Schmidt 2012-01-31 19:19:12 EST
What NFS protocol version do you use?
Could you attach /etc/fstab please?
Would you capture dmesg as in comment #1 once again?
Comment 9 Blakkheim.GW 2012-02-01 02:35:27 EST
We use NFSv3.

The revelant parts of /etc/fstab are these :

<servername>:/907/cust_tc    /cust_tc    nfs    rw 0 0
<servername>:/907/cust    /cust    nfs    rw 0 0
<servername>:/907/public    /public    nfs    rw 0 0
<servername>:/srv/Ptech    /Ptech    nfs    rw 0 0


I attach dmesg.
Comment 10 Blakkheim.GW 2012-02-01 02:36:14 EST
Created attachment 558765 [details]
Output of dmesg
Comment 11 Michal Schmidt 2012-02-01 04:30:22 EST
I see. There are actually several bugs in the NFS-related units:

- rpcbind.socket MUST NOT even exist until rpcbind supports socket activation.
  The socket right now serves no useful purpose and even causes harm because the
  listening socket acts as a trap for processes that connect to it.
  Already reported as bug 747363.

- If I'm not mistaken, rpc.statd (from nfs-lock.service) must be running before
  an NFS mount is attempted.
  The ordering can be ensured by adding two lines to the [Unit] section of
  nfs-lock.service:
    Wants=remote-fs-pre.target
    Before=remote-fs-pre.target

- The previous point probably holds for nfs-idmap.service as well.

Reassigning to nfs-utils.
Comment 12 Harald Hoyer 2012-02-21 07:20:43 EST
(In reply to comment #9)
> We use NFSv3.
> 
> The revelant parts of /etc/fstab are these :
> 
> <servername>:/907/cust_tc    /cust_tc    nfs    rw 0 0
> <servername>:/907/cust    /cust    nfs    rw 0 0
> <servername>:/907/public    /public    nfs    rw 0 0
> <servername>:/srv/Ptech    /Ptech    nfs    rw 0 0
> 
> 
> I attach dmesg.

You should probably also specify "nfsvers=3" in the filesystem options
Comment 13 Michal Schmidt 2012-02-28 07:04:13 EST
*** Bug 798234 has been marked as a duplicate of this bug. ***
Comment 14 Michal Schmidt 2012-03-07 08:51:44 EST
*** Bug 799990 has been marked as a duplicate of this bug. ***
Comment 15 Fedora Update System 2012-03-16 11:21:37 EDT
nfs-utils-1.2.5-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-5.fc16
Comment 16 Fedora Update System 2012-03-16 11:24:07 EDT
nfs-utils-1.2.5-13.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-13.fc17
Comment 17 Michal Schmidt 2012-03-19 10:11:29 EDT
*** Bug 773078 has been marked as a duplicate of this bug. ***
Comment 18 Fedora Update System 2012-03-22 20:40:55 EDT
Package nfs-utils-1.2.5-13.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.5-13.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4479/nfs-utils-1.2.5-13.fc17
then log in and leave karma (feedback).
Comment 19 Fedora Update System 2012-03-23 20:26:14 EDT
nfs-utils-1.2.5-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2012-05-08 00:11:22 EDT
nfs-utils-1.2.5-14.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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