[opensuse-factory] wow
Hello, I just did a fresh installation of factory. Network manager in KDE displays an error, but networking seems to work fine. $SUBJECT is "wow" because I don't recall openSUSE booting ever so fast! What was changed? I did not check with a timer, but it seems to be faster now than other distros, while earlier openSUSE was among the slow starters. Not that it matters on a machine I turn on only once a day, but still :-) Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2014-01-24 14:07, lynn wrote:
On Fri, 2014-01-24 at 09:39 +0100, Peter Czanik wrote:
What was changed?
I believe it is to do with systemd. It works now.
Did you add an SSD? ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 24 Jan 2014 09:39:42 +0100 Peter Czanik wrote:
$SUBJECT is "wow" because I don't recall openSUSE booting ever so fast! What was changed?
No "wow" here. % systemd-analyze blame | head 20.848s wicked.service 6.310s systemd-tmpfiles-clean.service 2.722s systemd-fsck@dev-disk-by\x2did-ata\x2dST340016A_3HS2P9CK\x2dpart1.service 2.078s raw.service 2.044s cycle.service 1.792s accounts-daemon.service 1.776s systemd-fsck-root.service 1.765s dev-mqueue.mount 1.765s dev-hugepages.mount 1.684s systemd-udev-root-symlink.service -- WBR Kyrill
On Tue, 28 Jan 2014 18:58:26 +0400
Kyrill Detinov
$SUBJECT is "wow" because I don't recall openSUSE booting ever so fast! What was changed?
No "wow" here.
% systemd-analyze blame | head 20.848s wicked.service 6.310s systemd-tmpfiles-clean.service
Hi,
Could you append the following line to the /etc/sysconfig/network/config
WICKED_DEBUG_PARAM='--debug all'
restart and provide the log of wicked.service (journalctl -u
wicked.service).
We could see there where it stalls.
--
Best Regards,
Pawel Wieczorkiewicz
Am 28.01.2014 15:58, schrieb Kyrill Detinov:
On Fri, 24 Jan 2014 09:39:42 +0100 Peter Czanik wrote:
$SUBJECT is "wow" because I don't recall openSUSE booting ever so fast! What was changed?
No "wow" here.
% systemd-analyze blame | head 20.848s wicked.service
This depends on the hardware and configuration. In my case with two
intel nics [AFAIR ~3-4s for hw/kernel init] with dhcp4 + dhcp6 + bridge
it is:
# systemd-analyze blame | grep wicked.service
13.615s wicked.service
Further, it is the starter service which basically waits (intentionally
delays) an amount of time until the nics are configured.
But there is still enough room to improve / tune.
I'd like have hw-init + 3s at the end ... :-)
I've reconfigured my box to use 1 nic and rebooted several times to
see which part is slow:
wicked-1-nic-dhcp4+6.out: 13.370s wicked.service
wicked-1-nic-dhcp4.out: 13.419s wicked.service
wicked-1-nic-dhcp6.out: 7.675s wicked.service
wicked-1-nic-static.out: 3.682s wicked.service
wicked-lo-only.out: 43ms wicked.service
Basically, it is wickedd-dhcp4 which starts to send packets too *early*
[nic not yet ready] and runs into retransmissions with increased timers:
2014-01-29T13:42:51.798106+01:00 wickedd-dhcp4[1005]: sending
DHCP4_DISCOVER with xid 0x2584a577
...
2014-01-29T13:43:00.802965+01:00 wickedd-dhcp4[1005]: nic0: retransmit
request
2014-01-29T13:43:00.803303+01:00 wickedd-dhcp4[1005]: arming retransmit
timer (9000 msec)
2014-01-29T13:43:00.805023+01:00 wickedd-dhcp4[1005]: sending
DHCP4_REQUEST with xid 0x2584a578
2014-01-29T13:43:00.804278+01:00 wickedd-dhcp4[1005]: nic0: received
DHCP4_OFFER message in state SELECTING
2014-01-29T13:43:00.805023+01:00 wickedd-dhcp4[1005]: sending
DHCP4_REQUEST with xid 0x2584a578
2014-01-29T13:43:00.806017+01:00 wickedd-dhcp4[1005]: nic0: received
DHCP4_ACK message in state REQUESTING
2014-01-29T13:43:00.811222+01:00 wickedd-dhcp4[1005]: arp_validate:
probing for 172.16.20.4
2014-01-29T13:43:01.411374+01:00 wickedd-dhcp4[1005]: successfully
validated 172.16.20.4
2014-01-29T13:43:01.417268+01:00 wickedd-dhcp4[1005]: nic0: committing lease
This needs to be addressed to work the right way. Even this, it works
and is not really worser than before.
A "modprobe af_packet" in StartPre of wickedd-dhcp4 should be a fast
workaround.
Here some logs from the wickedd-dhcp6:, which shows the times
that the things need, when __almost__ everything is basically fine:
* "ip link set up" send and reported by kernel:
2014-01-29T13:44:13.759304+01:00 wickedd-dhcp6[1010]: nic0[2]: received
interface event: device-up
* link goes up in the kernel:
2014-01-29T13:44:17.082206+01:00 kernel: [ 10.420396] IPv6:
ADDRCONF(NETDEV_CHANGE): nic0: link becomes ready
* dhcp6 noticed link up event, but ipv6 is not yet ready:
2014-01-29T13:44:17.098535+01:00 wickedd-dhcp6[1010]: nic0: Link-local
IPv6 address not (yet) available
* now ipv6 / the fe80... link-local address is ready:
2014-01-29T13:44:19.067329+01:00 wickedd-dhcp6[1010]: nic0: Found usable
link-local IPv6 address: fe80::xxxxxxxxxx
* rfc wait [this can be skipped, we already were waiting for fe80,
but as you'll see below, the first packet is still send too early
and we need 1 retransmission ;-]
2014-01-29T13:44:19.069069+01:00 nic0: setting timeout to 1025 msec
* first packet sent out:
2014-01-29T13:44:20.093116+01:00 wickedd-dhcp6[1010]: nic0: SOLICIT
message #1, xid 0x690d65 sent with 66 of 66 byte to ff02::1:2
* second packet send out [retransmission]:
2014-01-29T13:44:21.043018+01:00 wickedd-dhcp6[1010]: nic0: SOLICIT
message #2, xid 0x690d65 sent with 66 of 66 byte to ff02::1:2
* response from dhcp6 server:
2014-01-29T13:44:21.057165+01:00 nic0: received REPLY message xid
0x690d65 in state SELECTING from fe80::xxxxxxxxxx
...
rapid-commit: enabled -> can commit it
* send lease to wickedd:
2014-01-29T13:44:21.060058+01:00 wickedd-dhcp6[1010]:
dhcp6_protocol_event(ev=0, dev=2, uuid=9df7e852-6793-0b00-e403-000002000000)
* address applied to kernel:
2014-01-29T13:44:21.060969+01:00 wickedd[996]: Adding new interface
address 2001:XXX:XXXX:XXXX::4/64
2014-01-29T13:44:21.061112+01:00 wickedd[996]:
__ni_rtnl_send_newaddr(2001:XXX:XXXX:XXXX::4/64)
* address changed from "tentative" [dupplicate address check]
to "normal", wickedd-dhcp6 noticed this and schedules RENEW:
2014-01-29T13:44:22.170383+01:00 wickedd-dhcp6[1010]: nic0: Reached
BOUND state, scheduled RENEW in 3599 sec
Gruesse / Regards,
Marius Tomaschewski
On Wed, 29 Jan 2014 15:05:16 +0100 Marius Tomaschewski wrote:
This depends on the hardware and configuration.
Yes, it is (I think). Let say that to end-user. I have two NICs. The second one is disabled. No IPv6 here. I've disabled services: systemctl disable wickedd-dhcp6.service wickedd-nanny.service wickedd-dhcp4.service wickedd-auto4.service And what is annoying, after wicked update the services are active again. 22:07 kent@lazy ~ % systemd-analyze blame 21.076s wicked.service 6.823s apparmor.service -- WBR Kyrill
On Sun, Feb 02, Kyrill Detinov wrote:
22:07 kent@lazy ~ % systemd-analyze blame 21.076s wicked.service
Thats meaningless. Follow Pawels advice from 29.01. Thanks. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 2 Feb 2014 20:36:40 +0100 Olaf Hering wrote:
22:07 kent@lazy ~ % systemd-analyze blame 21.076s wicked.service
Thats meaningless. Follow Pawels advice from 29.01. Thanks.
Are you sure we have this advice in the Release Notes? Let start again. I am an end user. I don't read opensuse-factory@ mailing list. -- WBR Kyrill
On Sun, Feb 02, Kyrill Detinov wrote:
On Sun, 2 Feb 2014 20:36:40 +0100 Olaf Hering wrote:
22:07 kent@lazy ~ % systemd-analyze blame 21.076s wicked.service
Thats meaningless. Follow Pawels advice from 29.01. Thanks.
Are you sure we have this advice in the Release Notes?
Surely not, but to quote it again:
Could you append the following line to the /etc/sysconfig/network/config
WICKED_DEBUG_PARAM='--debug all'
restart and provide the log of wicked.service (journalctl -u wicked.service). We could see there where it stalls.
Thanks. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 2 Feb 2014 20:57:24 +0100 Olaf Hering wrote:
Could you append the following line to the /etc/sysconfig/network/config
WICKED_DEBUG_PARAM='--debug all'
restart and provide the log of wicked.service (journalctl -u wicked.service). We could see there where it stalls.
Hello. It was done in my message sent 29.01. http://susepaste.org/view/simple/22642677 Thanks. -- WBR Kyrill
On Mon, Feb 03, Kyrill Detinov wrote:
On Sun, 2 Feb 2014 20:57:24 +0100 Olaf Hering wrote:
restart and provide the log of wicked.service (journalctl -u wicked.service).
It was done in my message sent 29.01. http://susepaste.org/view/simple/22642677
This was not sent to the public. Unfortunately it contains only output from wicked(1) itself. At the end there are timeout messages? Please try to grep all wicked related messages, something like this should work: journalctl -an 12345 | grep wicked Thanks. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 3 Feb 2014 09:50:37 +0100 Olaf Hering wrote:
Please try to grep all wicked related messages, something like this should work: journalctl -an 12345 | grep wicked
Here is the output: http://susepaste.org/view/simple/76126425 Thanks. -- WBR Kyrill
On Mon, Feb 03, Kyrill Detinov wrote:
On Mon, 3 Feb 2014 09:50:37 +0100 Olaf Hering wrote:
Please try to grep all wicked related messages, something like this should work: journalctl -an 12345 | grep wicked
Here is the output: http://susepaste.org/view/simple/76126425
Thanks. Is there no wickedd-dhcp4/wickedd-dhcp6 running on your system? There is no output from these helpers in the log. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Feb 03, Kyrill Detinov wrote:
On Mon, 3 Feb 2014 11:04:43 +0100 Olaf Hering wrote:
Is there no wickedd-dhcp4/wickedd-dhcp6 running on your system? There is no output from these helpers in the log.
I have disabled DHCP and IPv6 services.
Please post the relevant ifcfg files so that wicked.rpm can also handle this case at some point. Like "head -n 42 /etc/sysconfig/network/ifcfg-*". Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 3 Feb 2014 12:15:03 +0100 Olaf Hering wrote:
Please post the relevant ifcfg files so that wicked.rpm can also handle this case at some point. Like "head -n 42 /etc/sysconfig/network/ifcfg-*".
==> /etc/sysconfig/network/ifcfg-eth0 <== BOOTPROTO='static' STARTMODE='auto' NAME='88E8053 PCI-E Gigabit Ethernet Controller' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='172.31.1.3/24' MTU='7200' NETWORK='' REMOTE_IPADDR='' USERCONTROL='no' ==> /etc/sysconfig/network/ifcfg-eth1 <== BOOTPROTO='dhcp4' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='CK804 Ethernet Controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='ifplugd' USERCONTROL='no' IFPLUGD_PRIORITY='nil' -- WBR Kyrill
I still have the problem. % cat /etc/os-release NAME=openSUSE VERSION="13.2 Milestone 0 (Harlequin)" VERSION_ID="13.2milestone0" PRETTY_NAME="openSUSE 13.2 Milestone 0 (Harlequin) (x86_64)" ID=opensuse ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:opensuse:13.2" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://opensuse.org/" ID_LIKE="suse" % systemd-analyze blame 30.455s wicked.service 10.753s systemd-fsck@dev-md0.service 2.779s systemd-fsck@dev-disk-by\x2did-ata\x2dST340016A_3HS2P9CK\x2dpart1.service 2.302s systemd-udev-root-symlink.service 2.061s raw.service 1.824s systemd-fsck-root.service 1.742s systemd-modules-load.service 1.586s systemd-vconsole-setup.service 1.582s dev-mqueue.mount 1.574s dev-hugepages.mount 1.561s accounts-daemon.service 1.278s systemd-tmpfiles-setup-dev.service 1.262s polkit.service ... On Mon, 3 Feb 2014 12:15:03 +0100 Olaf Hering wrote:
Please post the relevant ifcfg files so that wicked.rpm can also handle this case at some point. Like "head -n 42 /etc/sysconfig/network/ifcfg-*".
# head -n 42 /etc/sysconfig/network/ifcfg-* ==> /etc/sysconfig/network/ifcfg-eth0 <== BOOTPROTO='static' STARTMODE='auto' NAME='88E8053 PCI-E Gigabit Ethernet Controller' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='172.31.1.3/24' MTU='7200' NETWORK='' REMOTE_IPADDR='' USERCONTROL='no' ==> /etc/sysconfig/network/ifcfg-eth1 <== BOOTPROTO='dhcp4' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='CK804 Ethernet Controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='ifplugd' USERCONTROL='no' IFPLUGD_PRIORITY='nil' ==> /etc/sysconfig/network/ifcfg-lo <== # Loopback (lo) configuration IPADDR=127.0.0.1/8 NETMASK=255.0.0.0 NETWORK=127.0.0.0 BROADCAST=127.255.255.255 STARTMODE=nfsroot BOOTPROTO=static USERCONTROL=no FIREWALL=no Is there a way to debug the issue? -- WBR Kyrill
В Sun, 30 Mar 2014 01:34:18 +0400
Kyrill Detinov
% systemd-analyze blame 30.455s wicked.service
...
==> /etc/sysconfig/network/ifcfg-eth1 <== BOOTPROTO='dhcp4'
...
Is there a way to debug the issue?
Try manually different dhcp clients (dhcpclient, NetworkManager) and check timing. How much time they need to acquire address? If they appear to be significantly faster - it would point at wicked implementation.
On Sun, 30 Mar 2014 08:11:17 +0400 Andrey Borzenkov wrote:
% systemd-analyze blame 30.455s wicked.service ...
==> /etc/sysconfig/network/ifcfg-eth1 <== BOOTPROTO='dhcp4' ...
Is there a way to debug the issue?
Try manually different dhcp clients (dhcpclient, NetworkManager) and check timing. How much time they need to acquire address? If they appear to be significantly faster - it would point at wicked implementation.
The fact is, eth1 isn't connected. It was in state "STARTMODE='ifplugd'". I have disabled eth1 at all at the moment. And wicked service looks much better: % systemd-analyze blame 4.159s wicked.service 2.403s systemd-udev-root-symlink.service 2.189s systemd-vconsole-setup.service 2.057s raw.service ... So, the question is: does wicked know anything about ifplugd? -- WBR Kyrill
Am 01.04.2014 19:59, schrieb Kyrill Detinov:
On Sun, 30 Mar 2014 08:11:17 +0400 Andrey Borzenkov wrote:
% systemd-analyze blame 30.455s wicked.service ...
==> /etc/sysconfig/network/ifcfg-eth1 <== BOOTPROTO='dhcp4' ...
Is there a way to debug the issue?
Try manually different dhcp clients (dhcpclient, NetworkManager) and check timing. How much time they need to acquire address? If they appear to be significantly faster - it would point at wicked implementation.
The fact is, eth1 isn't connected. It was in state "STARTMODE='ifplugd'". I have disabled eth1 at all at the moment. And wicked service looks much better:
% systemd-analyze blame 4.159s wicked.service 2.403s systemd-udev-root-symlink.service 2.189s systemd-vconsole-setup.service 2.057s raw.service ...
So, the question is: does wicked know anything about ifplugd?
Not yet, we are currently working on it. At the moment it is same
to STARTMODE=hotplug, where we don't wait until the link is ready.
Basically, currently there is wicked.service, which starts & waits
until network is UP [network.target and network-online.target].
Later, there will be two services. First one just sets the config
and starts the ifup [network.target reached], the second waits for
the interfaces to get UP & running [network-online.target].
The network-online.target is pulled in by the consumer, that is a
service has to request it. See also "man 7 systemd.special".
We're currently working on the wickedd-nanny use, that is the first
service will just push the configs (as policies) into nanny.
The configuration of the interface will be done in nanny then.
The second one, will wait until the required links [!hotplug &&
!ifplugd] are up and running.
Effectively, the network.target will be reached quite fast (<~2sec?);
the second is intended to wait.
Gruesse / Regards,
Marius Tomaschewski
Am 29.03.2014 22:34, schrieb Kyrill Detinov:
I still have the problem.
[...]
% systemd-analyze blame 30.455s wicked.service
[...]
# head -n 42 /etc/sysconfig/network/ifcfg-* ==> /etc/sysconfig/network/ifcfg-eth0 <== BOOTPROTO='static' STARTMODE='auto' NAME='88E8053 PCI-E Gigabit Ethernet Controller' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='172.31.1.3/24' MTU='7200' NETWORK='' REMOTE_IPADDR='' USERCONTROL='no'
==> /etc/sysconfig/network/ifcfg-eth1 <== BOOTPROTO='dhcp4' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='CK804 Ethernet Controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='ifplugd' USERCONTROL='no' IFPLUGD_PRIORITY='nil'
^^^^^^^^^^^^^^^^^^^^^^ invalid. set to 0. but it should not hurt at the moment.
==> /etc/sysconfig/network/ifcfg-lo <== # Loopback (lo) configuration IPADDR=127.0.0.1/8 NETMASK=255.0.0.0 NETWORK=127.0.0.0 BROADCAST=127.255.255.255 STARTMODE=nfsroot BOOTPROTO=static USERCONTROL=no FIREWALL=no
Is there a way to debug the issue?
Set DEBUG=all in /etc/sysconfig/network/config, reboot and attach
"journalctl -b -o short-iso" output.
Either open a bug report or send it to wicked-devel@opensuse.org.
We try to "monitor" all lists, but it is hard to catch everything.
Gruesse / Regards,
Marius Tomaschewski
Peter Czanik wrote:
Hello, I just did a fresh installation of factory. Network manager in KDE displays an error, but networking seems to work fine. $SUBJECT is "wow" because I don't recall openSUSE booting ever so fast!
How fast. How long from when you have a choice of OS's in grub and select one till you can login? 10-15s? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.03.2014 07:07, schrieb Linda Walsh:
Peter Czanik wrote:
Hello, I just did a fresh installation of factory. Network manager in KDE displays an error, but networking seems to work fine. $SUBJECT is "wow" because I don't recall openSUSE booting ever so fast!
How fast. How long from when you have a choice of OS's in grub and select one till you can login? 10-15s?
Exactly. seife@susi:~> systemd-analyze Startup finished in 3.605s (kernel) + 10.899s (userspace) = 14.505s seife@susi:~> systemd-analyze blame|head -1 4.054s systemd-cryptsetup@cr_sda7.service I just cannot type my passphrase faster :-) There's probably some potential for optimizing the 3s in kernel by disabling drivers etc, but that's just not worth it for me. Oh - and that's a full desktop system +tor (which takes ~2 seconds to start) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-03-30 15:12, Stefan Seyfried wrote:
Am 30.03.2014 07:07, schrieb Linda Walsh:
How fast. How long from when you have a choice of OS's in grub and select one till you can login? 10-15s?
Exactly. seife@susi:~> systemd-analyze Startup finished in 3.605s (kernel) + 10.899s (userspace) = 14.505s
systemd-analyze times boot, not login.
seife@susi:~> systemd-analyze blame|head -1 4.054s systemd-cryptsetup@cr_sda7.service
I just cannot type my passphrase faster :-)
Then your password is exceedingly short and simple :-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 30.03.2014 15:33, schrieb Carlos E. R.:
On 2014-03-30 15:12, Stefan Seyfried wrote:
Am 30.03.2014 07:07, schrieb Linda Walsh:
How fast. How long from when you have a choice of OS's in grub and select one till you can login? 10-15s?
Exactly. seife@susi:~> systemd-analyze Startup finished in 3.605s (kernel) + 10.899s (userspace) = 14.505s
systemd-analyze times boot, not login.
Yes, but it measures until gdm is up AFAICT. There I need to give my password anyway.
seife@susi:~> systemd-analyze blame|head -1 4.054s systemd-cryptsetup@cr_sda7.service
I just cannot type my passphrase faster :-)
Then your password is exceedingly short and simple :-p
No, it's not, I type fast, blind with 10 fingers, but still less than 3 to four second is almost impossible to achieve with my filesystem password :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Andrey Borzenkov -
Carlos E. R. -
Jan Engelhardt -
Kyrill Detinov -
Linda Walsh -
lynn -
Marius Tomaschewski -
Olaf Hering -
Pawel Wieczorkiewicz -
Peter Czanik -
Stefan Seyfried