Bug 1419351 - on boot exports fail due to network not up
Summary: on boot exports fail due to network not up
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 25
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-05 18:20 UTC by Tom Shield
Modified: 2017-07-17 21:23 UTC (History)
9 users (show)

Fixed In Version: nfs-utils-2.1.1-4.rc2.fc26 nfs-utils-2.1.1-4.rc2.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-01 17:35:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1409012 0 low CLOSED nfs-server runs before network is ready; "failed to resolve" for all hosts; nothing is exported 2021-02-22 00:41:40 UTC

Internal Links: 1409012

Description Tom Shield 2017-02-05 18:20:47 UTC
Description of problem:

On boot exports fail:

Feb 02 15:19:05 localhost.localdomain systemd[1]: Starting NFS server and services...
Feb 02 15:19:05 localhost.localdomain exportfs[912]: exportfs: Failed to resolve yflyer
(and rest of export list fails similarly)

Version-Release number of selected component (if applicable):

nfs-utils-2.1.1-1.fc25.x86_64

How reproducible:

every time

Steps to Reproduce:
1. enable nfs-server to start on boot.  Add exports to /etc/exports. Using NetworkManager to start wired network via dhcp.  Have NetworkManager-wait-online.service enabled.
2.  reboot
3.  

Actual results:

exports are not exported

Expected results:

exports will be exported

Additional info:

Note error messages above: nfs server is trying to do export even before local host name is set from dhcp using systemd-hostnamed.service.

Adding

After=network-online.target

to nfs-server.service solves the problem.

I did not have this problem in Fedora 23 (I did not even have NetworkManager-wait-online enabled there) on the same machine (I just rebooted back into F23 to check).

Openvpn also has the same problem (and the same solution works), so I don't know if this is a problem with nfs-utils or NetworkManager or systemd. Or perhaps a change that was made to NetworkManager or systemd that makes this addition necessary.

Comment 1 Steve Dickson 2017-04-07 15:12:30 UTC
Started the upstream discussion 
    http://marc.info/?l=linux-nfs&m=149157766819591&w=2

Comment 2 Fedora Update System 2017-04-10 22:57:13 UTC
nfs-utils-2.1.1-4.rc2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bca43e3f7e

Comment 3 Fedora Update System 2017-04-11 00:26:43 UTC
nfs-utils-2.1.1-4.rc2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-218c78b2e7

Comment 4 Yu Watanabe 2017-04-11 01:41:21 UTC
Why do you only add Wants=network-online.target ?
Wants= option is independent of After= option.
So you should also add After=network-online.target, unless if you really do not want to care the order of that the network becomes online and that the NFS related services are started.

See systemd.unit(5). In the description of the "Requires=" option,
> If a unit foo.service requires a unit bar.service as configured 
> with Requires= and no ordering is configured with After= or Before=, 
> then both units will be started simultaneously and without any 
> delay between them if foo.service is activated.

Comment 5 Tom Shield 2017-04-11 19:18:04 UTC
I installed nfs-utils-2.1.1-4.rc2.fc25.x86_64 and moved my service file in /etc/systemd/system out of the way, disabled and re-enabled nfs-server and rebooted:

[root@taylor ~]# journalctl -r -u nfs-server.service
-- Logs begin at Mon 2017-01-16 13:19:53 CST, end at Tue 2017-04-11 14:11:28 CDT. --
Apr 11 14:10:41 localhost.localdomain systemd[1]: Started NFS server and services.
Apr 11 14:10:41 localhost.localdomain exportfs[830]: exportfs: Failed to resolve laser

so I agree that wants is not enough, my addition of after as above is what works for me.

Restarting the nfs-server.service does bring it up.

Comment 6 Steve Dickson 2017-04-13 00:12:03 UTC
(In reply to Yu Watanabe from comment #4)
> Why do you only add Wants=network-online.target ?
> Wants= option is independent of After= option.
> So you should also add After=network-online.target, unless if you really do
> not want to care the order of that the network becomes online and that the
> NFS related services are started.
There is the upstream discussion
    https://www.spinics.net/lists/linux-nfs/msg63132.html

It seems the systemd.special(7) man page says to use Wants=

Units that strictly require a configured network connection should
pull in network-online.target (via a Wants= type dependency) and
order themselves after it. This target unit is intended to pull in
a service that delays further execution until the network is
sufficiently set up. What precisely this requires is left to the
implementation of the network managing service.

Comment 7 Tom Shield 2017-04-13 00:21:51 UTC
(In reply to Steve Dickson from comment #6)
> (In reply to Yu Watanabe from comment #4)
> > Why do you only add Wants=network-online.target ?
> > Wants= option is independent of After= option.
> > So you should also add After=network-online.target, unless if you really do
> > not want to care the order of that the network becomes online and that the
> > NFS related services are started.
> There is the upstream discussion
>     https://www.spinics.net/lists/linux-nfs/msg63132.html
> 
> It seems the systemd.special(7) man page says to use Wants=
> 
> Units that strictly require a configured network connection should
> pull in network-online.target (via a Wants= type dependency) and
> order themselves after it. This target unit is intended to pull in
> a service that delays further execution until the network is
> sufficiently set up. What precisely this requires is left to the
> implementation of the network managing service.

I read "and order themselves after it" to mean that you should also use After= along with Wants=.

Comment 8 Fedora Update System 2017-04-14 17:20:11 UTC
nfs-utils-2.1.1-4.rc2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 9 Yu Watanabe 2017-04-19 06:35:36 UTC
(In reply to Tom Shield from comment #7)
> I read "and order themselves after it" to mean that you should also use
> After= along with Wants=.

Yes. Right.
Please do not close this bug. This bug is not fixed yet.

Comment 10 Fedora Update System 2017-04-19 09:23:36 UTC
nfs-utils-2.1.1-4.rc2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 11 Tom Shield 2017-04-19 15:27:45 UTC
(In reply to Fedora Update System from comment #10)
> nfs-utils-2.1.1-4.rc2.fc25 has been pushed to the Fedora 25 stable
> repository. If problems still persist, please make note of it in this bug
> report.

Already did note that this is not fixed.  See comment #5.

Comment 12 Steve Dickson 2017-04-19 15:42:53 UTC
(In reply to Tom Shield from comment #5)
> I installed nfs-utils-2.1.1-4.rc2.fc25.x86_64 and moved my service file in
> /etc/systemd/system out of the way, disabled and re-enabled nfs-server and
> rebooted:
If you moved a service file out of the way, How do you expect things to work?

> 
> [root@taylor ~]# journalctl -r -u nfs-server.service
> -- Logs begin at Mon 2017-01-16 13:19:53 CST, end at Tue 2017-04-11 14:11:28
> CDT. --
> Apr 11 14:10:41 localhost.localdomain systemd[1]: Started NFS server and
> services.
> Apr 11 14:10:41 localhost.localdomain exportfs[830]: exportfs: Failed to
> resolve laser
> 
> so I agree that wants is not enough, my addition of after as above is what
> works for me.
> 
> Restarting the nfs-server.service does bring it up.

Comment 13 Tom Shield 2017-04-19 15:52:08 UTC
(In reply to Steve Dickson from comment #12)
> (In reply to Tom Shield from comment #5)
> > I installed nfs-utils-2.1.1-4.rc2.fc25.x86_64 and moved my service file in
> > /etc/systemd/system out of the way, disabled and re-enabled nfs-server and
> > rebooted:
> If you moved a service file out of the way, How do you expect things to work?
> 

Note the path.  I moved my edited service file (as described in the original bug report) in /etc/systemd/system out of the way so that the updated one in /lib/systemd/system would be picked up and linked to by the enable command.

When you put edited/custom service files in /etc/systemd/system (so updates don't over write them) you need to disable and enable the service again to get the links updated.  Same is true when you remove a service file in /etc/systemd/system.

Comment 14 Steve Dickson 2017-04-19 15:54:54 UTC
Note, I started an upstream discussion 
    http://marc.info/?l=linux-nfs&m=149261158415078&w=2

Maybe you could add to it?

Comment 15 Steve Dickson 2017-04-24 16:53:03 UTC
The upstream posting
   http://marc.info/?l=linux-nfs&m=149304767813604&w=2

Comment 16 Tom Shield 2017-05-10 19:14:52 UTC
just installed nfs-utils.x86_64 1:2.1.1-5.rc2.fc25 and rebooted.  Nfs exports succeeded.  Addition of After= network-online.target seems to have solved the problem.  Thanks.


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