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