Red Hat Bugzilla – Full Text Bug Listing
|Summary:||insufficient ordering of NFS-related units|
|Product:||[Fedora] Fedora||Reporter:||Blakkheim.GW <blakkheim.gw>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||bfields, fedora, harald, jlayton, johannbg, metherid, mschmidt, notting, plautrba, ron, steved, systemd-maint, yves.pausch|
|Fixed In Version:||nfs-utils-1.2.5-14.fc17||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-23 20:26:14 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 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 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.