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:
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
It turnes out that "eternity" == max 10 min.
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.
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.
Yet another old netbook has the same problem with RC5/Cauldron: The WiFi connection comes up 10 min after the boot.
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
Assignee: bugsquad => mageia
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 => ???????????
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.
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
(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
Created attachment 6313 [details] journalctl -b > journalctl-b.txt This journal is taken 10min after a boot when the interface came up.
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?
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...
And if that does not help, try to disable chrony-wait.service to confirm it's the one delayng your system
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.
Never enable chrony-wait.service!
Status: NEW => REOPENED
Closing this. It was chrony-wait.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED