Comment # 17 on bug 1132774 from Michal Koutn�

The problems with DBus name discovery are only a consequence of wickedd start
(that prusumably provides the interface) failed. 

In comment 15, we can see the start timed out because of ExecStartPre= (already
pointed out above):

> Jun 14 11:43:51.036047 SoftironGGA systemd[1]: Starting wicked network management service daemon...
> Jun 14 11:44:42.406809 SoftironGGA systemd-udevd[474]: e0010000.kcs: Worker [494] processing SEQNUM=2154 is taking a long time
> Jun 14 11:45:21.156747 SoftironGGA systemd[1]: wickedd.service: Start-pre operation timed out. Terminating.
> Jun 14 11:45:21.169538 SoftironGGA systemd[1]: wickedd.service: Control process exited, code=killed, status=15/TERM
> Jun 14 11:45:21.169689 SoftironGGA systemd[1]: wickedd.service: Failed with result 'timeout'.

The directive was added in:
version-0.6.54~1^2 6b1f8ed18f25 ("systemd: ask udev to settle before wickedd
runs")
However, the commit message does not explain why.

If the intention was to wait for all devices are discovered, then the proper
way is to pull in dependency on systemd-udev-settle.service, i.e.

    Wants=systemd-udev-settle.service # or Requires=
    After=systemd-udev-settle.service

This way the time spent is accounted where it should be
(systemd-udev-settle.service) and it is up to wickedd to fail on its own when
it's missing some devices.

Another problem is why a particular udev worker gets apparently stuck:

Jun 14 11:44:42.406809 SoftironGGA systemd-udevd[474]: e0010000.kcs: Worker
[494] processing SEQNUM=2154 is taking a long time

(as per comment 3, it's not a device necessary for networking though).