Bug 1073419 - NetworkManager-wait-online finishes before any ethernet device gets configured
Summary: NetworkManager-wait-online finishes before any ethernet device gets configured
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-06 12:13 UTC by Tomas Smetana
Modified: 2014-10-14 13:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-14 13:49:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Excerpt from /var/log/messages (12.03 KB, text/plain)
2014-03-06 12:15 UTC, Tomas Smetana
no flags Details
New /var/log/messages excerpt (10.34 KB, text/plain)
2014-03-13 09:38 UTC, Tomas Smetana
no flags Details

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


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