[opensuse] Wicked 30s Timeout on boot of 42.3 - how to fix?
All, As I sort out the 42.3 install, I'm down my checklist to "Why does wicked create a 30s delay in the boot process?" Basically, after systemd-analyze plot > opensuse_42.3_boot_delay.svg there is no question who/what the culprit is: Apr 18 17:15:24 wizard systemd[1]: Starting wicked managed network interfaces... Apr 18 17:15:54 wizard wicked[1159]: lo up Apr 18 17:15:54 wizard wicked[1159]: wlan0 up Apr 18 17:15:54 wizard wicked[1159]: eth0 setup-in-progress Apr 18 17:15:54 wizard systemd[1]: Started wicked managed network interfaces.
From 17:15:24 - to - 17:15:54, wicked is just sitting there spinning its wheels.
Anybody else see something similar? Anybody know how to fix it? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin composed on 2018-04-18 17:44 (UTC-0500):
As I sort out the 42.3 install, I'm down my checklist to "Why does wicked create a 30s delay in the boot process?" Basically, after
systemd-analyze plot > opensuse_42.3_boot_delay.svg
there is no question who/what the culprit is:
Apr 18 17:15:24 wizard systemd[1]: Starting wicked managed network interfaces... Apr 18 17:15:54 wizard wicked[1159]: lo up Apr 18 17:15:54 wizard wicked[1159]: wlan0 up Apr 18 17:15:54 wizard wicked[1159]: eth0 setup-in-progress Apr 18 17:15:54 wizard systemd[1]: Started wicked managed network interfaces.
From 17:15:24 - to - 17:15:54, wicked is just sitting there spinning its wheels.
Anybody else see something similar? Anybody know how to fix it?
Happens to me when the ethernet cable is not plugged in securely. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/18/2018 06:01 PM, Felix Miata wrote:
As I sort out the 42.3 install, I'm down my checklist to "Why does wicked create a 30s delay in the boot process?" Basically, after systemd-analyze plot > opensuse_42.3_boot_delay.svg there is no question who/what the culprit is: Apr 18 17:15:24 wizard systemd[1]: Starting wicked managed network interfaces... Apr 18 17:15:54 wizard wicked[1159]: lo up Apr 18 17:15:54 wizard wicked[1159]: wlan0 up Apr 18 17:15:54 wizard wicked[1159]: eth0 setup-in-progress Apr 18 17:15:54 wizard systemd[1]: Started wicked managed network interfaces.
From 17:15:24 - to - 17:15:54, wicked is just sitting there spinning its wheels. Anybody else see something similar? Anybody know how to fix it? Happens to me when the ethernet cable is not plugged in securely.
I have unplugged my ethernet after install, so this is just bringing wlan0 up. It looks like there is something left in the setup that is waiting for eth0. That interface should just be brought up, but wicked shouldn't be waiting for it to get an address. Yast says under eth0 (General) Activate Device is set to "At Boot Time" - should I change that to On Cable Connect On Hotplug It doesn't hurt to bring the "device" up, it just shouldn't activate the device until the cable is plugged in. I'll try "On Cable Connect" and see what that does, but I recall having some issues with that during days gone by. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/19/2018 12:17 AM, David C. Rankin wrote:
I have unplugged my ethernet after install, so this is just bringing wlan0 up. It looks like there is something left in the setup that is waiting for eth0. That interface should just be brought up, but wicked shouldn't be waiting for it to get an address.
Yast says under eth0 (General) Activate Device is set to "At Boot Time" - should I change that to
On Cable Connect On Hotplug
It doesn't hurt to bring the "device" up, it just shouldn't activate the device until the cable is plugged in. I'll try "On Cable Connect" and see what that does, but I recall having some issues with that during days gone by.
That didn't work, on clicking OK in yast after changing to "On Cable Connect", yast hung for 30 seconds and then shut down. I do not have IPv6, but have not disabled it in yast. I thought development there had progressed far enough that it wouldn't cause a hang? I have no problems with NM on Arch leaving IPv6 enabled and didn't think that would be a problem here. It has been years since I've seen a "disable IPv6" thread on this list. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 04/19/2018 12:17 AM, David C. Rankin wrote:
I have unplugged my ethernet after install, so this is just bringing wlan0 up. It looks like there is something left in the setup that is waiting for eth0. That interface should just be brought up, but wicked shouldn't be waiting for it to get an address.
Yast says under eth0 (General) Activate Device is set to "At Boot Time" - should I change that to
On Cable Connect On Hotplug
It doesn't hurt to bring the "device" up, it just shouldn't activate the device until the cable is plugged in. I'll try "On Cable Connect" and see what that does, but I recall having some issues with that during days gone by.
That didn't work, on clicking OK in yast after changing to "On Cable Connect", yast hung for 30 seconds and then shut down.
I do not have IPv6, but have not disabled it in yast. I thought development there had progressed far enough that it wouldn't cause a hang?
Unless you have an actually faulty IPv6 setup, there is no need to disable it, correct. -- Per Jessen, Zürich (11.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi david, i could confirm this behavior on opensuse tumbleweed also. (desktop computer) it installed automatically wicked. so always when i use this computer without network cable plugged in, the 30 seconds delay is there. ipv6 is disabled. do you found a solution? simoN Am 19.04.2018 um 07:23 schrieb David C. Rankin:
On 04/19/2018 12:17 AM, David C. Rankin wrote:
I have unplugged my ethernet after install, so this is just bringing wlan0 up. It looks like there is something left in the setup that is waiting for eth0. That interface should just be brought up, but wicked shouldn't be waiting for it to get an address.
Yast says under eth0 (General) Activate Device is set to "At Boot Time" - should I change that to
On Cable Connect On Hotplug
It doesn't hurt to bring the "device" up, it just shouldn't activate the device until the cable is plugged in. I'll try "On Cable Connect" and see what that does, but I recall having some issues with that during days gone by.
That didn't work, on clicking OK in yast after changing to "On Cable Connect", yast hung for 30 seconds and then shut down.
I do not have IPv6, but have not disabled it in yast. I thought development there had progressed far enough that it wouldn't cause a hang? I have no problems with NM on Arch leaving IPv6 enabled and didn't think that would be a problem here. It has been years since I've seen a "disable IPv6" thread on this list.
- -- www.becherer.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJa2DHcAAoJEOuDxDCJWQG+NwwQAKWS2/N7pmUT4kUkwxUcFldt Fo4ZOj1L7nsQSbPVjkk+yvNjJqUbTikbN42L6DcLEClMmQH85TFN+iXZCbN3jya8 s+WWVQY39Jj4YNtRshmtQ1olXinBOMK+kU40b0dTrp20PffpS+yKBaws5DxFbkfY BHeUECScMaeXe0MNDBfVky+AiGQW2yMedE5VmwrNRA9rn5r81qpAM1QDnLigBUL5 NFudeX1atGOXRhu5O1B+WFYj/7RFF4uAg0/ikN8ckGLE+4gbu4uwlTO8xtsXIE+G OK00/sSWV/cfcjGcwKpDBpaqwzmlbp76hjRwbcKlY5cpi0dveGEfILwSkoh+gkGn 0XBPigCBBbFsBP+dmUXAjvwlVzaKqTn7vNLUMXTzoifjoj+LZsRlezJQbHhIAPkm krw918Sq0TbybLB3e6cGzQLHw4gTsHO1m9HsS583YpBqKYwMfjbqyxMO2srxe2gh 7a/vDpxHrew5JsLP1xymAdQ94PGRlScu/iZhArhUwI3HDw/QV01ZA3ROKddI2fO6 VoLb190/A/mm2Q1snpgKng6Kpv/kD3ASePimXr0IRG78I+jkfEdcuE3I+uhbynw4 Uexu4Nf6MU9lPWI4DOI45VGGQJ3QOorMONs5aArPLGGNeKBzU9I2CydVroefurWl C09D4//9wyuOTDEEyhz+ =XlsJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin composed on 2018-04-19 00:17 (UTC-0500):
Felix Miata wrote:
Happens to me when the ethernet cable is not plugged in securely.
I have unplugged my ethernet after install, so this is just bringing wlan0 up. It looks like there is something left in the setup that is waiting for eth0. That interface should just be brought up, but wicked shouldn't be waiting for it to get an address.
Yast says under eth0 (General) Activate Device is set to "At Boot Time" - should I change that to
On Cable Connect On Hotplug
It doesn't hurt to bring the "device" up, it just shouldn't activate the device until the cable is plugged in.
Makes sense to me. Grep of icked from 15.0b journal tail: Apr 19 02:18:18 gb250 systemd[1]: Starting wicked DHCPv4 supplicant service... Apr 19 02:18:18 gb250 systemd[1]: Starting wicked DHCPv6 supplicant service... Apr 19 02:18:18 gb250 systemd[1]: Starting wicked AutoIPv4 supplicant service... Apr 19 02:18:18 gb250 systemd[1]: Started wicked DHCPv4 supplicant service. Apr 19 02:18:18 gb250 systemd[1]: Started wicked AutoIPv4 supplicant service. Apr 19 02:18:18 gb250 systemd[1]: Started wicked DHCPv6 supplicant service. Apr 19 02:18:18 gb250 systemd[1]: Starting wicked network management service daemon... Apr 19 02:18:19 gb250 systemd[1]: Started wicked network management service daemon. Apr 19 02:18:19 gb250 systemd[1]: Starting wicked network nanny service... Apr 19 02:18:19 gb250 systemd[1]: Started wicked network nanny service. Apr 19 02:18:19 gb250 systemd[1]: Starting wicked managed network interfaces... Apr 19 02:18:49 gb250 wicked[660]: lo up Apr 19 02:18:49 gb250 wicked[660]: eth0 setup-in-progress Apr 19 02:18:49 gb250 systemd[1]: Started wicked managed network interfaces. 30 second needless wait. Nothing I own uses anything but wired ethernet. Only about 2 out of hundreds or maybe thousands of installations going back to RedHat 5 here have been configured to use DHCP. All the rest, including those that lose 30 seconds to Wicked at boot if the cable isn't properly connected, use fixed IP. I don't remember ever having any such delay from ifup at boot time, when networks that didn't need to be "managed" weren't. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
Makes sense to me. Grep of icked from 15.0b journal tail:
[snip - wicked log output]
30 second needless wait.
An hour ago, I rebooted my Leap15 server - 2018-04-19T08:03:34+02:00 jensen systemd[1]: Starting wicked managed network interfaces... 2018-04-19T08:03:44+02:00 jensen wicked[943]: lo up 2018-04-19T08:03:44+02:00 jensen wicked[943]: eth1 up 2018-04-19T08:03:44+02:00 jensen wicked[943]: eth0 up 2018-04-19T08:03:44+02:00 jensen systemd[1]: Started wicked managed network interfaces. Static config, 10 second wait. I don't think it's a bug, it is something in the environment. -- Per Jessen, Zürich (13.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-19 09:18, Per Jessen wrote:
Felix Miata wrote:
Makes sense to me. Grep of icked from 15.0b journal tail:
[snip - wicked log output]
30 second needless wait.
An hour ago, I rebooted my Leap15 server -
2018-04-19T08:03:34+02:00 jensen systemd[1]: Starting wicked managed network interfaces... 2018-04-19T08:03:44+02:00 jensen wicked[943]: lo up 2018-04-19T08:03:44+02:00 jensen wicked[943]: eth1 up 2018-04-19T08:03:44+02:00 jensen wicked[943]: eth0 up 2018-04-19T08:03:44+02:00 jensen systemd[1]: Started wicked managed network interfaces.
Static config, 10 second wait. I don't think it's a bug, it is something in the environment.
<3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Started wicked AutoIPv4 supplicant service. <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Started wicked DHCPv4 supplicant service. <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Started wicked DHCPv6 supplicant service. <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Starting wicked network management service daemon... <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Started wicked network management service daemon. <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Starting wicked network nanny service... <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Started wicked network nanny service. <3.6> 2018-03-28 12:59:10 Telcontar systemd 1 - - Starting wicked managed network interfaces... <3.6> 2018-03-28 12:59:31 Telcontar wicked 1823 - - lo up <3.6> 2018-03-28 12:59:31 Telcontar wicked 1823 - - eth0 up <3.6> 2018-03-28 12:59:31 Telcontar wicked 1823 - - eth1 setup-in-progress <3.6> 2018-03-28 12:59:31 Telcontar systemd 1 - - Started wicked managed network interfaces. Interestingly, I see almost nothing when coming out of hibernation: <3.4> 2018-04-19 11:18:24 Telcontar wickedd 1813 - - route ipv4 0.0.0.0/0 via 192.168.1.1 dev eth0#2 type unicast table main scope universe protocol boot covered by a ipv4:static lease -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Felix Miata composed on 2018-04-19 02:38 (UTC-0400):
Makes sense to me. Grep of icked from 15.0b journal tail: ... Apr 19 02:18:19 gb250 systemd[1]: Started wicked network nanny service. Apr 19 02:18:19 gb250 systemd[1]: Starting wicked managed network interfaces... Apr 19 02:18:49 gb250 wicked[660]: lo up Apr 19 02:18:49 gb250 wicked[660]: eth0 setup-in-progress Apr 19 02:18:49 gb250 systemd[1]: Started wicked managed network interfaces.
30 second needless wait.
Nothing I own uses anything but wired ethernet. Only about 2 out of hundreds or maybe thousands of installations going back to RedHat 5 here have been configured to use DHCP. All the rest, including those that lose 30 seconds to Wicked at boot if the cable isn't properly connected, use fixed IP. I don't remember ever having any such delay from ifup at boot time, when networks that didn't need to be "managed" weren't.
Since for me this dates back to 13.2 and happens on both 15.0 and TW, I decided to go ahead and file a bug, even though only some installations have this problem: http://bugzilla.opensuse.org/show_bug.cgi?id=1090188 -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/19/2018 04:44 AM, Felix Miata wrote:
Since for me this dates back to 13.2 and happens on both 15.0 and TW, I decided to go ahead and file a bug, even though only some installations have this problem: http://bugzilla.opensuse.org/show_bug.cgi?id=1090188
I added my information as well, thanks. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.04.2018 04:57, David C. Rankin пишет:
On 04/19/2018 04:44 AM, Felix Miata wrote:
Since for me this dates back to 13.2 and happens on both 15.0 and TW, I decided to go ahead and file a bug, even though only some installations have this problem: http://bugzilla.opensuse.org/show_bug.cgi?id=1090188
I added my information as well, thanks.
Yet another "bug report" that just wastes scarce time of developers. This is normal behavior, wicked waits for link on device, if you do not like it - disable it. How to do it is described in (surprise) "man ifcfg". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov composed on 2018-04-21 08:44 (UTC+0300):
David C. Rankin composed:
Felix Miata wrote:
Since for me this dates back to 13.2 and happens on both 15.0 and TW, I decided to go ahead and file a bug, even though only some installations have this problem: http://bugzilla.opensuse.org/show_bug.cgi?id=1090188
I added my information as well, thanks.
Yet another "bug report" that just wastes scarce time of developers.
This is normal behavior, wicked waits for link on device, if you do not like it - disable it. How to do it is described in (surprise) "man ifcfg".
If you look at note 1 in comment 0 of the bug you might notice among the 3 openSUSE installations on the same machine, two have the problem, the other does not. All three have the identical BOOTPROTO, STARTMODE and IPADDR lines that the YaST installer created and no other lines in /etc/sysconfig/network/ifcfg-<NIC>. All were installed within a matter of hours from each other using the same installation cmdline network specification (per LINUXRC). Why the difference in behavior among the three installations? Does Wicked assign a random value for LINK_REQUIRED in the bowels of /usr/ or elsewhere when YaST doesn't configure one in ifcfg-<NIC>? LINK_REQUIRED='no' I found thanks to Andrei does keep wicked startup time the same with or without ethernet cable connected. :-) -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2018 02:18 AM, Felix Miata wrote:
Andrei Borzenkov composed on 2018-04-21 08:44 (UTC+0300):
David C. Rankin composed:
Felix Miata wrote:
Since for me this dates back to 13.2 and happens on both 15.0 and TW, I decided to go ahead and file a bug, even though only some installations have this problem: http://bugzilla.opensuse.org/show_bug.cgi?id=1090188
I added my information as well, thanks.
Yet another "bug report" that just wastes scarce time of developers.
This is normal behavior, wicked waits for link on device, if you do not like it - disable it. How to do it is described in (surprise) "man ifcfg".
If you look at note 1 in comment 0 of the bug you might notice among the 3 openSUSE installations on the same machine, two have the problem, the other does not. All three have the identical BOOTPROTO, STARTMODE and IPADDR lines that the YaST installer created and no other lines in /etc/sysconfig/network/ifcfg-<NIC>. All were installed within a matter of hours from each other using the same installation cmdline network specification (per LINUXRC). Why the difference in behavior among the three installations? Does Wicked assign a random value for LINK_REQUIRED in the bowels of /usr/ or elsewhere when YaST doesn't configure one in ifcfg-<NIC>?
LINK_REQUIRED='no' I found thanks to Andrei does keep wicked startup time the same with or without ethernet cable connected. :-)
Felix, THANK YOU!!! for pointing me in the right direction. The problem is the openSuSE config for wicked. Buried down in /etc/sysconfig/network/config is: WAIT_FOR_INTERFACES="30" which cannot be set via YAST/Nework (your adapter). 30 seconds twiddling thumbs is a ridiculous amount of time to wait for interfaces that come up instantaneously. Setting it to "5" is more than sufficient. Then next problem is the global default of auto for: ## Type: list(auto,yes,no) ## Default: "auto" # # Permits to specify/modify a global ifcfg default. Use with care! # # This settings breaks rules for many things, which require carrier # before they can start, e.g. L2 link protocols, link authentication, # ipv4 duplicate address detection, ipv6 duplicate detection will # happen "post-mortem" and maybe even cause to disable ipv6 at all. # See also "man ifcfg" for further informations. # LINK_REQUIRED="auto" (apparently "auto" means yes) This appears to be a holdover from the days you had to wait for a carrier before they can start. Thanks to Felix, I found this and set it to "no" on a per-interface basis in ifcfg-eth0, e.g. $ cat /etc/sysconfig/network/ifcfg-eth0 LINK_REQUIRED="no" BOOTPROTO='dhcp' STARTMODE='onboot' BROADCAST='' ETHTOOL_OPTIONS='' IFPLUGD_PRIORITY='0' IPADDR='' MTU='' NAME='' NETMASK='' NETWORK='' REMOTE_IPADDR='' There is no way to set this through yast/network either. After making these changes, there is no 5 second delay at boot and the system comes right up: -- Logs begin at Mon 2018-04-02 18:49:33 CDT, end at Sat 2018-04-21 04:04:17 CDT. -- Apr 21 03:52:53 wizard systemd[1]: Starting wicked managed network interfaces... Apr 21 03:52:58 wizard wicked[1122]: lo setup-in-progress Apr 21 03:52:58 wizard wicked[1122]: wlan0 setup-in-progress Apr 21 03:52:58 wizard wicked[1122]: eth0 setup-in-progress Apr 21 03:52:58 wizard systemd[1]: Started wicked managed network interfaces. Creating and checking a plot of the startup: $ systemd-analyze plot > opensuse_boot.svg Shows I could reduce this further, as nothing is waiting on any of the devices, and SuSEFirewall comes right up (925ms) as soon as the 5 second delay times out. The 30 second delay is way way too long. Especially for my HP laptop that just sits there stalled until 1/2 minute rolls by until wicked times out and I can finish boot. After the changes, the entire boot, from Off/Cold to Kdm login takes less than the 30 seconds I would otherwise be waiting on wicked. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 21/04/2018 à 11:16, David C. Rankin a écrit :
WAIT_FOR_INTERFACES="30"
what surprise me is why is not this wait parallelized, that is done still continuing boot for the other parts? fact is I never notice such delay booting my laptops :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
Le 21/04/2018 à 11:16, David C. Rankin a écrit :
WAIT_FOR_INTERFACES="30"
what surprise me is why is not this wait parallelized, that is done still continuing boot for the other parts?
Anything that does not require network should bve contin\uing, I would expect.
fact is I never notice such delay booting my laptops :-(
This thread clearly shows that people have different experiences with this. -- Per Jessen, Zürich (19.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks david and the others here for the detailed description, it will save in the next 10 years proximately 21 hours of my live!!! - -> 5 days a week needless 30s wait time...... simoN www.becherer.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJa2ypWAAoJEOuDxDCJWQG+8PMQAJHdDwGaFEDngA9Ng+IsgEqH 04EenxsG5yulPf1SefB8HtE5Yi8PZmcCeHY/i1zAJpjXcjwSnEf1pnHQ25tVEQno hnktus1F2jUpA+IjUgUfFZiSg3jobYrOTXHdlTRaiP2cQ2kn+AdcNPzJ76lsNzMW BREyqCql9NqZFq28SdRGiFtlNhRhMJqi6ZzdvLpuRzDersn3R3NcEPNCPF7QP6Yp UREohv81elXJ2cyZDDaPgMZRgjeRPSuWoE+1lsmMq2gPGkuEihVckKnqa0o4dqR+ +AR89EuO83jOs8/CSOwNi+79SeVL9U250BgCRWdF9nxBDGR99t/4XPO3CRLNmNtl EfxEA8CkpfepoF3XC6NqSc8n/0VwwunV//rHDVnMYvhbVUwO60Ryjca5rR62Ohd3 S1OnjlcbjocXH/ri21KJ7ye5zL0L6aUwVmyIJfbgYhhQis2CwpUbqkkr+Mh20Ky4 E5ZdhFSul0HUhiSU433YmXbCQXkdJ36wlkWp6c1wgP5x0YmUG3L/mZYLvYRE6MXK ghixuboxykocKEA9dMrxi3rl47LVSlmJmtQ+mUz7yoCclvvtH/VL8E5EISq3AjY8 gJcZYsdM+JW7jWGNEe6YvZm9Gyg9aAPm6N7mYhTpDDhL7AsLiHkjI0VDUp9Sl22D /P3Sjij6hGwuM+BjI3wX =0lEm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2018 04:16 AM, David C. Rankin wrote:
reating and checking a plot of the startup:
$ systemd-analyze plot > opensuse_boot.svg
Shows I could reduce this further, as nothing is waiting on any of the devices, and SuSEFirewall comes right up (925ms) as soon as the 5 second delay times out.
Hell yes! After making the final tweak: # /etc/sysconfig/network/config WAIT_FOR_INTERFACES="1" I boot from cold-start to full desktop in 12.135 seconds! That's what systemd is supposed to do, not some snoozer of almost a full-minute to boot. The proof is in the pudding: $ systemd-analyze Startup finished in 5.433s (kernel) + 3.511s (initrd) + 3.190s (userspace) = 12.135s 1 2 . 1 3 5 S e c o n d s ! ! ! Y a B a b y ! ! ! Just by getting wicked fixed made all the difference in the world (well 30+ seconds difference). We don't have to wait for modems to find a carrier anymore, and there is no reason that boot shouldn't execute wicked startup in parallel with all that doesn't depend on network. Right now there is a dead 30 delay in boot where wicked just blocks waiting on eth0 (which isn't even plugged in). This may not occur for all NICs, but it does for my: Intel Corporation 82579LM Gigabit Network Connection (rev 04) (and that's not some strange or rare NIC) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2018 01:17 PM, David C. Rankin wrote:
After making the final tweak:
# /etc/sysconfig/network/config WAIT_FOR_INTERFACES="1"
I boot from cold-start to full desktop in 12.135 seconds! That's what systemd is supposed to do, not some snoozer of almost a full-minute to boot. The proof is in the pudding:
$ systemd-analyze Startup finished in 5.433s (kernel) + 3.511s (initrd) + 3.190s (userspace) = 12.135s
1 2 . 1 3 5 S e c o n d s ! ! ! Y a B a b y ! ! !
Just by getting wicked fixed made all the difference in the world (well 30+ seconds difference). We don't have to wait for modems to find a carrier anymore, and there is no reason that boot shouldn't execute wicked startup in parallel with all that doesn't depend on network. Right now there is a dead 30 delay in boot where wicked just blocks waiting on eth0 (which isn't even plugged in).
Thanks to all for this thread. Now my system (13.1) boot time is less than half what it was. I used 5 as wait time instead of 30 and get 19s instead of the 43s before. Thanks again! - Fred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-21 20:17, David C. Rankin wrote:
On 04/21/2018 04:16 AM, David C. Rankin wrote:
reating and checking a plot of the startup:
$ systemd-analyze plot > opensuse_boot.svg
Shows I could reduce this further, as nothing is waiting on any of the devices, and SuSEFirewall comes right up (925ms) as soon as the 5 second delay times out.
Hell yes!
After making the final tweak:
# /etc/sysconfig/network/config WAIT_FOR_INTERFACES="1"
I had it at 20, and yes, I'm getting a 20" delay. Will see on next boot, I set it to 5. I have one network interface unconfigured, maybe that is an issue.
I boot from cold-start to full desktop in 12.135 seconds! That's what systemd is supposed to do, not some snoozer of almost a full-minute to boot. The proof is in the pudding:
$ systemd-analyze Startup finished in 5.433s (kernel) + 3.511s (initrd) + 3.190s (userspace) = 12.135s
1 2 . 1 3 5 S e c o n d s ! ! ! Y a B a b y ! ! !
Startup finished in 1.984s (kernel) + 8.760s (initrd) + 1min 44.189s (userspace) = 1min 54.933s Some of that time is the password entry for encrypted partition, part the 20" of network. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Hi! Am Samstag, 21. April 2018, 11:16:22 CEST schrieb David C. Rankin:
THANK YOU!!! for pointing me in the right direction. The problem is the openSuSE config for wicked. Buried down in /etc/sysconfig/network/config is:
WAIT_FOR_INTERFACES="30"
which cannot be set via YAST/Nework (your adapter). 30 seconds twiddling thumbs is a ridiculous amount of time to wait for interfaces that come up instantaneously. Setting it to "5" is more than sufficient.
Thank you so very much for this! The issue has been annoying me for months but I never had the spare time to dig into now. Now my system is up in an instant. Thank you! Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
On Sunday, April 22, 2018 3:16:51 PM EDT Matthias Bach wrote:
which cannot be set via YAST/Nework (your adapter).
But it can be set via YaST /etc/sysconfig editor under Network/General. --dg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2018 12:44 AM, Andrei Borzenkov wrote:
Yet another "bug report" that just wastes scarce time of developers.
This is normal behavior, wicked waits for link on device, if you do not like it - disable it. How to do it is described in (surprise) "man ifcfg".
Andrei, If that is the normal behavior, then the devs have configured the default behavior wrong. Bringing up the "device" should happen at boot instantaneously. (and it does). Waiting for an IP on eth0 configured with "On Cable Connect" is just wrong. Why the hell is there an option for "On Cable Connect" if the software is just going to block on boot waiting for an IP that will never come -- because there is no cable plugged in -- and never will be. When there is no cable, the device should simply be brought up, and then wicked should attempt to establish a connection on wlan0, not stall on eth0 waiting for an empty RJ-45 socket to do something it may, or may not, ever do. I dual triple boot this laptop, openSuSE, Win10, and Arch. All OS'es have the cable and wireless devices enable. openSuSE is the only one with a 30 second delay in boot. That's not normal behavior. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
All,
As I sort out the 42.3 install, I'm down my checklist to "Why does wicked create a 30s delay in the boot process?" Basically, after
systemd-analyze plot > opensuse_42.3_boot_delay.svg
there is no question who/what the culprit is:
Apr 18 17:15:24 wizard systemd[1]: Starting wicked managed network interfaces... Apr 18 17:15:54 wizard wicked[1159]: lo up Apr 18 17:15:54 wizard wicked[1159]: wlan0 up Apr 18 17:15:54 wizard wicked[1159]: eth0 setup-in-progress Apr 18 17:15:54 wizard systemd[1]: Started wicked managed network interfaces.
From 17:15:24 - to - 17:15:54, wicked is just sitting there spinning its wheels.
Anybody else see something similar? Anybody know how to fix it?
I feel certain there is a bug report on something like that, but I can't find it. Looking at some different systems - jensen - Leap15 - 12seconds, office38 - leap15 - 30seconds. office37 - leap423 - 10seconds. test422 - leap423/xen - 9seconds. office31 - leap423 - 15seconds office36 - leap423 - 11seconds Apart from different hardware, virtually all the same. I think you need to look in the environment, I don't think it's a bug as such. -- Per Jessen, Zürich (9.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I feel certain there is a bug report on something like that, but I can't find it. Looking at some different systems -
jensen - Leap15 - 12seconds, office38 - leap15 - 30seconds. office37 - leap423 - 10seconds. test422 - leap423/xen - 9seconds. office31 - leap423 - 15seconds office36 - leap423 - 11seconds
Apart from different hardware, virtually all the same. I think you need to look in the environment, I don't think it's a bug as such.
On "office38", I had two non-existent interfaces defined (i.e. I had /etc/sysconfig/network/ifcfg-xxxxxx files). Here is a startup with both unchanged: 2018-04-19T09:38:21+02:00 linux-wvtd systemd[1]: Starting wicked managed network interfaces... 2018-04-19T09:38:28+02:00 linux-wvtd wickedd-dhcp4[991]: eth0: Request to acquire DHCPv4 lease with UUID 7047d85a-0c11-0900-e603-000005000000 2018-04-19T09:38:28+02:00 linux-wvtd wickedd-dhcp6[986]: eth0: Request to acquire DHCPv6 lease with UUID 7047d85a-0c11-0900-e603-000006000000 in mode auto 2018-04-19T09:38:29+02:00 linux-wvtd wickedd-dhcp4[991]: eth0: Committed DHCPv4 lease with address 192.168.3.38 (lease time 86400 sec, renew in 43200 sec, rebind in 75600 sec) 2018-04-19T09:38:30+02:00 office38 wickedd[998]: ni_process_reap: process 1512 has not exited yet; now doing a blocking waitpid() 2018-04-19T09:38:30+02:00 office38 wickedd-dhcp6[986]: eth0: link confirmed in reply with status Success - All addresses still on link. 2018-04-19T09:38:30+02:00 office38 wickedd-dhcp6[986]: eth0: Committed DHCPv6 lease with addresses: 2018-04-19T09:38:30+02:00 office38 wickedd-dhcp6[986]: 2a03:7520:4c68:1:ff99:ffff:0:1091, pref-lft 43200, valid-lft 86400 2018-04-19T09:38:54+02:00 office38 wicked[1015]: lo up 2018-04-19T09:38:54+02:00 office38 wicked[1015]: eth0 up 2018-04-19T09:38:54+02:00 office38 wicked[1015]: enp15s0 no-device 2018-04-19T09:38:54+02:00 office38 wicked[1015]: enp13s0 no-device 2018-04-19T09:38:54+02:00 office38 systemd[1]: Started wicked managed network interfaces. total 33 seconds. I then went and renamed them and rebooted: 2018-04-19T10:08:01+02:00 linux-wvtd systemd[1]: Starting wicked managed network interfaces... 2018-04-19T10:08:03+02:00 linux-wvtd wicked[930]: Rejecting suspect interface name: enp13s0.inactive 2018-04-19T10:08:03+02:00 linux-wvtd wicked[930]: Rejecting suspect interface name: enp15s0.inactive 2018-04-19T10:08:07+02:00 linux-wvtd wickedd-dhcp4[854]: eth0: Request to acquire DHCPv4 lease with UUID 634ed85a-b0ae-0d00-9d03-000005000000 2018-04-19T10:08:07+02:00 linux-wvtd wickedd-dhcp6[855]: eth0: Request to acquire DHCPv6 lease with UUID 634ed85a-b0ae-0d00-9d03-000006000000 in mode auto 2018-04-19T10:08:08+02:00 linux-wvtd wickedd-dhcp4[854]: eth0: Committed DHCPv4 lease with address 192.168.3.38 (lease time 86400 sec, renew in 43200 sec, rebind in 75600 sec) 2018-04-19T10:08:10+02:00 office38 wickedd-dhcp6[855]: eth0: link confirmed in reply with status Success - All addresses still on link. 2018-04-19T10:08:10+02:00 office38 wickedd-dhcp6[855]: eth0: Committed DHCPv6 lease with addresses: 2018-04-19T10:08:10+02:00 office38 wickedd-dhcp6[855]: 2a03:7520:4c68:1:ff99:ffff:0:1091, pref-lft 43200, valid-lft 86400 2018-04-19T10:08:11+02:00 office38 wicked[930]: lo up 2018-04-19T10:08:11+02:00 office38 wicked[930]: eth0 up 2018-04-19T10:08:11+02:00 office38 systemd[1]: Started wicked managed network interfaces. Total 10 seconds. David, I'm sure you're not having the exact same problem :-), but maybe this will give you some inspiration? -- Per Jessen, Zürich (15.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi
Apart from different hardware, virtually all the same. I think you need to look in the environment, I don't think it's a bug as such.
On "office38", I had two non-existent interfaces defined (i.e. I had /etc/sysconfig/network/ifcfg-xxxxxx files).
...snip
Total 10 seconds.
David, I'm sure you're not having the exact same problem :-), but maybe this will give you some inspiration?
at least here, i have only one network interface and only two ifcfg-xxx files (what seems to me correct): ifcfg-enp37s0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.0.5/24' MTU='' NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto ifcfg-lo # Loopback (lo) configuration IPADDR=127.0.0.1/8 NETMASK=255.0.0.0 NETWORK=127.0.0.0 STARTMODE=nfsroot BOOTPROTO=static USERCONTROL=no FIREWALL=no but have with unplugged ethernet cable always 30 seconds, with plugged in cable nearly nothing. simoN www.becherer.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJa2JGsAAoJEOuDxDCJWQG+wakQAOtoNB/l9eclJ4uJq2hKu2yo CVg30g9Zfs7N+hNOpUy6QlXIK+VaLDk7hEdZScil25DBk4D6uFA/ae8bR0AZtkrc OX6fIKXId0XDPD4WpjQhfDiSTH2NjlBPmSiYSrCVj5o3SPvtH7svbyk3Z0kNygue HlZWMdG6eH7H7i34YibOupJu7yTOfkIaFY6lXpJSwSQ3UkX+mdVrJr/F1fvMdziw 8E1fBfUfWCxHJpxeiJzdJeF0Uqe0K6YQC1ae9590QwEwxFc6BqiXUUX12FoJWoeI zQyItuH31apz3uIW3iTetTTumECBs6JI3A7mKYO2hOyiQxA2USZzwKRWiKazwlJ6 n/5CwuANjh4tNJnu2pTATWkiHsm0MAMXIzegLfJdKPGls7rbTppnnGrhS6AJXbWJ fr9eWZ6sM7a0Eb/Hv7M2LSRvSV7NCWfMB6dl1Jq74gGhILWS78b+YEc78slfl5Xa PijKPk/Ht6pDSssAYoK4Xn+gwvl4lIp4dsZQfsn1bBjA5pmxSVfYqz0LLu3vmw8i Ibf7KFkS8MtDNwhAzhiIl7aTJtL3y0IaypAZixY2yQlSN5r5hYd9aD0Fbh7vwFI6 ENzIXHA9ob9E30zfuuE+G+rzCBHJBPU3a1s4MGs19E/NNseWayCcBvFpYe9g+SX9 M64Im20juy5NNUhyMBLf =uLA+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Apart from different hardware, virtually all the same. I think you need to look in the environment, I don't think it's a bug as such.
A good candidate might be the switch. I have a 10G switch that has 'green ethernet ports'. They only power up when signal is detected, and so typically eat both the first DHCP packet as well as any WOL magic packet :( And because power saving is so essential the manufacturer decided you can NOT switch off this feature.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-19 13:05, Peter Suetterlin wrote:
Per Jessen wrote:
Apart from different hardware, virtually all the same. I think you need to look in the environment, I don't think it's a bug as such.
A good candidate might be the switch. I have a 10G switch that has 'green ethernet ports'. They only power up when signal is detected, and so typically eat both the first DHCP packet as well as any WOL magic packet :(
And because power saving is so essential the manufacturer decided you can NOT switch off this feature....
But this would not explain why the delay is consistently 20 seconds (and 30 on some systems). Nor why on recover from hibernation there is no delay at all. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 04/19/2018 06:17 AM, Carlos E. R. wrote:
But this would not explain why the delay is consistently 20 seconds (and 30 on some systems). Nor why on recover from hibernation there is no delay at all.
And certainly not explain my case where there is no-ethernet-cable plugged in. -- David C. Rankin, J.D.,P.E.
On 2018-04-21 03:59, David C. Rankin wrote:
On 04/19/2018 06:17 AM, Carlos E. R. wrote:
But this would not explain why the delay is consistently 20 seconds (and 30 on some systems). Nor why on recover from hibernation there is no delay at all.
And certainly not explain my case where there is no-ethernet-cable plugged in.
I had WAIT_FOR_INTERFACES="20" The default is 30. I guess somepeople have 20", that must have been the default at some time, and others have 30". -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Am 19.04.2018 um 13:05 schrieb Peter Suetterlin:
Per Jessen wrote:
Apart from different hardware, virtually all the same. I think you need to look in the environment, I don't think it's a bug as such.
A good candidate might be the switch. I have a 10G switch that has 'green ethernet ports'. They only power up when signal is detected, and so typically eat both the first DHCP packet as well as any WOL magic packet :(
And because power saving is so essential the manufacturer decided you can NOT switch off this feature....
Maybe i am to far away from the tecnical part to understand, but the waittime 30 30 seconds is always here without pysical ethernet cable plugged in, static ip adresses ipv4. and it happend never if the cable is plugged in. simoN - -- www.becherer.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJa2JAqAAoJEOuDxDCJWQG+wmoQAIf/ynfOJiU61CYzVH0ukOWZ EaySuqJeeVimgbZMcI8Wi/xQDl78SWNyGetMhgsfadOCZqkUzvXG9spJlFzKfMIC 0ogXleIXsYAqGUOlBrA8jPpg2EGW01u4Txw3SZQC10xvwxj4QJc5vZg2H0XHdz9r uyzOBiR24jcF2WDFJsKIuH87Fuoz4Cd8TV6x6625H2i9O8KHBkRU9i56L3+rx/3R C8HF9wmXcjxdUBuAEkQf+1dTWPJQoUp0YOVSIUJSdxZRD7SL0zbzntJcQbahVLPU OvV2bPF8utbVrY54R+4QriwPKO96LrZz3sf+8n4Y3pKI+TOr+8ZVwxP1cKai2Glt 73kh26JXHVkpJcEw6In9tNcUKHatV+J7dSL8r4Id6ScBY8Vp+G2vgRqdDy9KWdc/ bDAVO4w3ow6NdvnRYzGZI6m/4B/c724aYvpCXAonbmreLb0RMBdDGkyraE9VNdw4 QcmFjPnGtjz4azsuxNXPCjStZbw60QJxeVFbL3IiC/jlS5dw3pR5cOPmFgNQmBxq 0tj+2IvbLqssqGPcPk1b6FdC8bdm2wHAWhORp3wCMXCYUl1AkRa7KyEi3yefXjny OSeGoJKVf2089ESmjVZzKc7zFZFhzbYCeVBysXoR/jqEmHuO1aIVtTqCZJD2+cQe ue4zMerkCNKhajjmhQbc =wMtM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Donnerstag, 19. April 2018, 00:44:16 CEST schrieb David C. Rankin:
All,
As I sort out the 42.3 install, I'm down my checklist to "Why does wicked create a 30s delay in the boot process?"
As far as i know it's a bad interpretation of the DHCP protocol. The standard defines that a DHCP client shall insert a RANDOM delay of UP TO 30 seconds after start. The idea is that when an adminitrator wakes up a whole client network with tons of clients to install updates at night they don't all start hitting the DHCP server at the same time and break it. Some dhcp clients "misunderstood" that line and forgot the random part, doing a full 30 second delay. That's what I've been told. I have to admit that I haven't actually looked up the RFC yself so far... Cheers MH -- gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C
On 2018-04-19 08:35, Mathias Homann wrote:
Am Donnerstag, 19. April 2018, 00:44:16 CEST schrieb David C. Rankin:
All,
As I sort out the 42.3 install, I'm down my checklist to "Why does wicked create a 30s delay in the boot process?"
As far as i know it's a bad interpretation of the DHCP protocol. The standard defines that a DHCP client shall insert a RANDOM delay of UP TO 30 seconds after start. The idea is that when an adminitrator wakes up a whole client network with tons of clients to install updates at night they don't all start hitting the DHCP server at the same time and break it.
Some dhcp clients "misunderstood" that line and forgot the random part, doing a full 30 second delay.
That's what I've been told. I have to admit that I haven't actually looked up the RFC yself so far...
I use fixed IPs, no dhcp. The delay is 20 seconds, fixed, not random. This is a home, nobody else is loading the network. Two interfaces, one of them unused and unconfigured. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Thursday, April 19, 2018 5:49:27 AM EDT Carlos E. R. wrote:
I use fixed IPs, no dhcp. The delay is 20 seconds, fixed, not random. This is a home, nobody else is loading the network.
I wonder if this might be a factor . . . in all cases, using static ip over ethernet, always enabled. Last year using a router in which a static ip got assigned by adding the device to the dhcp table. Journalctl then showed this, 19 seconds: Jun 02 14:50:25 Alien-SuSE systemd[1]: Starting wicked managed network interfaces... Jun 02 14:50:27 Alien-SuSE wickedd-dhcp4[1551]: eth0: Request to acquire DHCPv4 lease with UUID 71b33159-816d-0900-5206-000005000000 Jun 02 14:50:27 Alien-SuSE wickedd-dhcp6[1542]: eth0: Request to acquire DHCPv6 lease with UUID 71b33159-816d-0900-5206-000006000000 in mode auto Jun 02 14:50:28 Alien-SuSE wickedd-dhcp4[1551]: eth0: Committed DHCPv4 lease with address 192.168.0.100 (lease time 172800 sec, renew in 86400 sec, rebind in 151200 sec) Jun 02 14:50:44 Alien-SuSE wicked[1626]: lo up Jun 02 14:50:44 Alien-SuSE wicked[1626]: eth0 up Jun 02 14:50:44 Alien-SuSE systemd[1]: Started wicked managed network interfaces. Or this, 31 seconds, 15 of which were a wait (held up by dhcp6?). Jun 01 15:51:49 Alien-SuSE systemd[1]: Starting wicked managed network interfaces... Jun 01 15:51:52 Alien-SuSE wickedd-dhcp4[1456]: eth0: Request to acquire DHCPv4 lease with UUID 56703059-ea8e-0600-e805-000005000000 Jun 01 15:51:52 Alien-SuSE wickedd-dhcp6[1462]: eth0: Request to acquire DHCPv6 lease with UUID 56703059-ea8e-0600-e805-000006000000 in mode auto Jun 01 15:52:02 Alien-SuSE wickedd-dhcp4[1456]: unable to confirm lease Jun 01 15:52:07 Alien-SuSE wickedd-dhcp4[1456]: eth0: defer timeout 15 reached (state INIT) Jun 01 15:52:20 Alien-SuSE wicked[1558]: lo up Jun 01 15:52:20 Alien-SuSE wicked[1558]: eth0 setup-in-progress Jun 01 15:52:20 Alien-SuSE systemd[1]: Started wicked managed network interfaces. But now using a different router, dhcp enabled, static ip configured separately, I get: Apr 18 13:46:58 Alien-SuSE systemd[1]: Starting wicked managed network interfaces... Apr 18 13:47:05 Alien-SuSE wicked[1507]: lo up Apr 18 13:47:05 Alien-SuSE wicked[1507]: eth0 up Apr 18 13:47:05 Alien-SuSE systemd[1]: Started wicked managed network interfaces. Only 7 seconds. The only variables are the routers, and openSUSE versions (currently 42.3, last year 42.1). It looks like the variation in times may be due to configuration and environment? --dg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (12)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
Dennis Gallien -
Felix Miata -
jdd＠dodin.org -
Mathias Homann -
Matthias Bach -
Per Jessen -
Peter Suetterlin -
Simon Becherer -
Stevens