Bug 15545 - Network comes up after 10min, but WatchdogSec=1min in systemd-network.service
Summary: Network comes up after 10min, but WatchdogSec=1min in systemd-network.service
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-20 20:56 CET by Bjarne Thomsen
Modified: 2015-05-13 15:25 CEST (History)
4 users (show)

See Also:
Source RPM: ???????????
CVE:
Status comment:


Attachments
journalctl -b > journalctl-b.txt (16.54 KB, application/x-xz)
2015-04-18 23:33 CEST, Bjarne Thomsen
Details

Description Bjarne Thomsen 2015-03-20 20:56:37 CET
Description of problem:
I have finally gotten an Aopen Digital Engine DE3250 with 2 ethernet ports, so that I can test the startup of the dhcpd server for the LAN (sharing the internet).
I started with the configuration of just one interface.
I worked quite well every time I logged into KDE4 after a reboot.

Then I configured the second interface with "Sharing the Internet" (drakgw).
After a reboot the net-applet told me that
"Network is down on interface Wired (enp1s0)".

I waited and waited (5 - 10 min) and was about to right click and select
"Connect Wired (enp1s0)" when enp1s0 suddenly connected to the Internet.
When I checked the status of dhcpd it was running and the other interface
enp2s0 was up.

Is "hot-plugging" normally that slow? Or am I supposed to remove the
cable and plug it in again?


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


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Bjarne Thomsen 2015-03-21 10:46:09 CET
First of all: It works! The 2 ethernet interfaces do come up, even if I am
not logged into KDE. And dhcpd.service is running, when I log into KDE.

But it feels like an eternity before it happens.
I assume this timing is done by systemd, but how and where can I
set it to a more convenient value?

Source RPM: drakx-net-applet (maybe) => It must be systemd

Comment 2 Bjarne Thomsen 2015-03-24 09:03:50 CET
It turnes out that "eternity" == max 10 min.
Comment 3 Bjarne Thomsen 2015-03-24 11:45:03 CET
The services starts 10 min and 15 s after start of boot.
The boot process takes about 15 s.
Evidently there is a delay of exactly 10 min.
Comment 4 Bjarne Thomsen 2015-03-24 16:09:38 CET
This problem is NOT limited to "sharing the internet" on an extra ethernet port.
An old netbook with ethernet and WiFi has the same problem:
the WiFi connection is only available 10 min after boot.
Comment 5 Bjarne Thomsen 2015-03-24 17:13:58 CET
Yet another old netbook has the same problem with RC5/Cauldron:
The WiFi connection comes up 10 min after the boot.
Comment 6 Bjarne Thomsen 2015-03-27 15:30:07 CET
I have changed the title to reflect the reality.
I havn't been able to find where the 10min come from.

Summary: Very slow hot-plugging of wired interface when "sharing the internet" => Network comes up after 10min, but WatchdogSec=1min in systemd-network.service

Bjarne Thomsen 2015-03-30 12:59:44 CEST

Assignee: bugsquad => mageia

Comment 7 Bjarne Thomsen 2015-04-05 09:07:47 CEST
I updated the first netbook to cauldron of April 4.
Then I removed the network interfaces an configured both ethernet
and Wi-Fi interfaces.
When the ethernet cable was removed I still had to wait 10m
for the Wi-Fi connection to come up.

The I made a fresh net-install with boot-nonfree.iso of April 3.
Now the Wi-Fi comes up emediately after a boot.
A fresh install also worked with the other netbook.
Is there more to a network interface than can be handled by the MCC??

Source RPM: It must be systemd => ???????????

Comment 8 Bjarne Thomsen 2015-04-05 09:21:15 CEST
Now I come to my Aopen DE3250 with 2 ethernet connections.
I made a fresh net-install with boot-nonfree.iso (x86_64) of Apr 3.
Then I made a static configuration of the first ethernet port for
the internet, and then sharing a local network on the second port.
After a reboot the situation was unchanged: I had to wait 10 min
for dhcpd to start.

BUT, After a couple of reboots it suddenly works!
The local network starts right after a reboot.

What is going on here? It looks as if there is more to this
problem than can be handled by the MCC.
Comment 9 Bjarne Thomsen 2015-04-18 19:19:41 CEST
The problem is back again after an update to the latest kernel followed
by a reboot. I have just kept updating frum cauldron for the last 14 days.
The 2 interfaces came up emediately after a reboot until now.
Now, again I have 2 wait 10min for both interfaces and the services to come up
after a reboot. This happens for both boxes: 1) Wi-Fi + eth and 2) eth + eth.

What is going on?

Assignee: mageia => bugsquad

Comment 10 Marja Van Waes 2015-04-18 19:50:11 CEST
(In reply to Bjarne Thomsen from comment #9)
> The problem is back again after an update to the latest kernel followed
> by a reboot. I have just kept updating frum cauldron for the last 14 days.
> The 2 interfaces came up emediately after a reboot until now.
> Now, again I have 2 wait 10min for both interfaces and the services to come
> up
> after a reboot. This happens for both boxes: 1) Wi-Fi + eth and 2) eth + eth.
> 
> What is going on?

Hi Bjarne,

I don't understand what's going on, either :-/
But since you've seen this happen on 3 different systems since you filed this bug report, it is unlikely that it is hardware related.

After booting into you system, can you wait those 10 minutes and then run (as root):
journalctl -b > journalctl-b.txt

and attach journalctl-b.txt to this bug report?
If it is very big, then please compress it, first
(e.g. with "xz journalctl-b.txt")

Cheers,
marja

CC: (none) => mageia, mageia, marja11, tmb

Comment 11 Bjarne Thomsen 2015-04-18 23:33:17 CEST
Created attachment 6313 [details]
journalctl -b > journalctl-b.txt

This journal is taken 10min after a boot when the interface came up.
Comment 12 Bjarne Thomsen 2015-04-18 23:36:23 CEST
There is a 5min wait after ionice and another 5min after checking network.
The same thing happens on my asus box.
Could it be important that I use btrfs on both systems?
Comment 13 Thomas Backlund 2015-04-19 00:31:11 CEST
The 10-minute delay comes from chrony
/usr/lib/systemd/system/chrony-wait.service

I also noticed in the logs you are using nscd, and spotted an error in our packaging of it, preventing it to work correctly.

I fixed that in glibc/nscd-2.20-18.mga5 that should soon land on mirrors.

So please update to that and see if it changes anything...
Comment 14 Thomas Backlund 2015-04-19 01:03:28 CEST
And if that does not help, try to disable chrony-wait.service to confirm it's the one delayng your system
Comment 15 Bjarne Thomsen 2015-04-19 03:29:08 CEST
It was chrony-wait.service! It has probably been the root of the trouble
all along. It is good to know. nscd was only installed on the Aopen box.
Comment 16 Bjarne Thomsen 2015-04-27 23:04:16 CEST
Never enable chrony-wait.service!

Status: NEW => REOPENED

Comment 17 Bjarne Thomsen 2015-05-13 15:25:10 CEST
Closing this. It was chrony-wait.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED


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