Bug 7140

Summary:	network-up does not wait long enough for network to be up when link down detected
Product:	Mageia	Reporter:	Samuel Verschelde <stormi-mageia>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	major
Priority:	Normal	CC:	mageia, nic, tmb, venomdoli4
Version:	Cauldron
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:	MGA2TOO
Source RPM:	initscripts	CVE:
Status comment:

Description Samuel Verschelde 2012-08-22 09:50:21 CEST

network-up waits only for 2 seconds (DEFAULT_LINK_DETECTION_DELAY=2) after seeing a link down, then it considers that the network has started.

In companies, there's a network feature that always waits a few seconds before actually powering a link, this time is used to detect loops. See https://en.wikipedia.org/wiki/Spanning_Tree_Protocol 

In my company, this makes network-up finish too early and subsequent services to start too early (such as winbind). Consequently users can't log in to the active directory.

Since now most things are parallelized, I suggest to increase the default value. It shouldn't slow down booting too much for laptops actually not connected to network. 

DEFAULT_LINK_DETECTION_DELAY=5 might be enough in most cases. If it doesn't impede starting delays too much, a higher value would be safer.

Samuel Verschelde 2012-08-22 09:50:40 CEST

CC: (none) => mageia
Whiteboard: (none) => MGA2TOO

Comment 1 Samuel Verschelde 2012-08-22 10:01:06 CEST

Example of logs that show a 3s delay between down and up:

Aug 22 08:41:27 tech009 kernel: [    9.317177] tg3 0000:02:00.0: eth0: Link is down
Aug 22 08:41:30 tech009 kernel: [   12.319472] tg3 0000:02:00.0: eth0: Link is up at 1000 Mbps, full duplex

Comment 2 Thomas Backlund 2012-08-22 14:53:57 CEST

You actually dont even need STP ho hit this issue.

There are atleast some Realtek PHYs that is known to need up to 5 seconds to fully init and detect link too

CC: (none) => tmb

Comment 3 Thomas Backlund 2012-08-22 14:56:31 CEST

Otoh this is nore of an admin / customizing config issue...

But maybe we could detect services that really need network to be up and slow down the detection...

Comment 4 Colin Guthrie 2012-08-22 15:12:19 CEST

Well there is the general concept of "network-up" which this script does, but it fails gracefully when there is no connection.

We could perhaps also have a service which waits for e.g. network-online. This could then be used for services which really do need the network to be online.

That said, starting "network-online.service" would be subject to the typical timeouts and would eventually fail to start. These timeouts could be tweaked of course, but if such services were part of the default.target, you'd end up with the knock on effect of the boot never technically "completing" until a network was present which I think is undesirable.

While systemd does allow a lot more to be done with dependencies than we've had in the past, it also encourages correct design in many cases. For me, the only "correct design" in this case is to make any services that really are dependant on network listen to netlink events and act properly and dynamically in and off themselves, not rely on and wait for some theoretical point in time that might never happen (or might happen, then unhappen, then rehappen!)

See: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/4960

Lennart's replies describe more eloquently than myself as to why this static approach isn't really scaleable.

NB: "NetworkManager-wait-online.service" is pretty similar to our network-up script.

Comment 5 Nic Baxter 2015-03-11 01:16:08 CET

My understanding of comment 4 is this is not something that should be fixed. Am I correct? If so should this be closed?

CC: (none) => nic

Comment 6 Samuel Verschelde 2016-10-15 20:23:02 CEST

Let's close it, yes.

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED

Rio Tokyo 2023-04-24 14:11:40 CEST

CC: (none) => venomdoli4