Skip to content

device: don't delay startup complete for pending-actions "autoconf", "dhcp4" and "dhcp6"

Thomas Haller requested to merge th/device-no-pending-action-for-dhcp into master


These "pending-actions" only have one purpose: to mark the device
as busy and thereby delay "startup complete" to be reached. That
in turn delays "NetworkManager-wait-online" service.

Of course, "NetworkManager-wait-online" waits for some form of readiness
and is not extensivley configurable (e.g. to exclude devices). However,
the intent is to wait that all devices are "settled". That means among
others, the timeouts waiting for carrier and Wi-Fi scan results passed,
devices either don't have a connection profile to autoactivate, or
that autoactivating profiles reach a state of activated.

A major point here is that the device is considered ready, once it
reaches the state "activate". Note that if you configure both IPv4 and
IPv6 addressing modes, than ipv4.may-fail=yes and ipv6.may-fail=yes
means, that the device is considered fully activated once one address
family completes. Again, this is not very configurable, but by setting
"ipv6.may-fail=no", you can require that the device has indeed IPv6
addressing completed.

Now, the determining factor for declaring "startup complete" is whether the
device is in state connected. That may or may not mean that DHCPv4,
autoconf or DHCPv6 completed, as it depends on a overall state of the
devic. So, it is wrong to have distrinct pending actions for these operations.

Remove them.

This fixes that we wrongly would wait too long before declaring startup

This is related to issue on the mailing list:

Merge request reports