Bug 1073419

Summary: NetworkManager-wait-online finishes before any ethernet device gets configured
Product: [Fedora] Fedora Reporter: Tomas Smetana <tsmetana>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: danw, dcbw, jklimes, jsynacek
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-10-14 13:49:04 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:
Description Flags
Excerpt from /var/log/messages
none
New /var/log/messages excerpt none

Description Tomas Smetana 2014-03-06 12:13:53 UTC 
Description of problem:
I'm trying to make SLP service working correctly in Rawhide. The service needs to set-up a multicast route so I changed its unit file to look like this:

[Unit]
Description=OpenSLP daemon for the Service Location Protocol
Requires=network-online.target
After=network-online.target

[Service]
Type=forking
ExecStart=/usr/sbin/slpd
ExecStartPre=/usr/lib/openslp-server/slp-multicast-set.sh

[Install]
WantedBy=multi-user.target

This still doesn't work and looking at the logs it seems that the NetworkManager-wait-online actually finishes, i.e. the network-online.target is reached as soon as the loopback device is configured.  This doesn't look like the intended behaviour to me.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.9.1-0.git20140228.fc21.x86_64

How reproducible:
Always

Steps to Reproduce:
1. systemctl enable NetworkManager-wait-online
2. reboot
3. check when the NetworkManager-wait-online finishes

Actual results:
"Reached target Network is Online." right after the lo interface is configured

Expected results:
"Reached target Network is Online." only after some/all of the non-loopback interfaces are configured.
Comment 1 Tomas Smetana 2014-03-06 12:15:40 UTC 
Created attachment 871385 [details]
Excerpt from /var/log/messages
Comment 2 Jirka Klimes 2014-03-12 13:25:45 UTC 
I haven't managed to reproduce the problem of NM declaring "startup complete" just after loopback.
However, there is a bug in nm-online that is now tracked in bug 1054364. And the issues can be related.

Tomas, could you try again with the newest NM build from Monday:
NetworkManager-0.9.9.1-1.git20140310.fc21

And also with scratch build containing nm-online patch from bug 1054364:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6625660
Comment 3 Tomas Smetana 2014-03-13 09:38:29 UTC 
Created attachment 873880 [details]
New /var/log/messages excerpt

Here's the messages created using the Koji build of NetworkManager-0.9.9.1-1_1.git20140310.fc21.  It looks like the ordering is OK now.  However it seems that Wait online is being started much later now.

The problem seems to be fixed for me however upon Jirka Klimes's request I'm leaving the bug open for now.
Comment 4 Dan Winship 2014-03-25 13:52:51 UTC 
(In reply to Tomas Smetana from comment #3)
> Created attachment 873880 [details]
> New /var/log/messages excerpt
> 
> Here's the messages created using the Koji build of
> NetworkManager-0.9.9.1-1_1.git20140310.fc21.  It looks like the ordering is
> OK now.  However it seems that Wait online is being started much later now.

Really? It's still showing "startup complete" before bringing up ens3...

What's supposed to happen is that it prints "startup complete" (and NM-wait-online exits) at the point where it knows that no further progress on the network configuration is going to be possible without user intervention. In your logs, something is going wrong and it's declaring startup complete before configuring ens0, but there's not enough info in the log excerpt to say why. There had been a bug before with devices that always reported no-carrier on startup regardless of their actual carrier state, but that should be fixed in the versions you tested.
Comment 5 Tomas Smetana 2014-10-14 11:19:52 UTC 
This looks like a forgotten one... Anyway: I don't experience the problems mentioned in the description on Rawhide today. Feel free to close this bug.
Comment 6 Dan Winship 2014-10-14 13:49:04 UTC 
Ah, yeah, this got debugged in RHEL bug reports and has been fixed upstream for a while