diff options
| author | Thomas Haller <thaller@redhat.com> | 2019-10-09 12:43:14 +0200 |
|---|---|---|
| committer | Thomas Haller <thaller@redhat.com> | 2019-10-14 11:35:40 +0200 |
| commit | 1e5206414af83ede1e4e1ff6f525161b83519845 (patch) | |
| tree | be21db9b1542868243d59617143995ccac9cca68 /NEWS | |
| parent | 95d0d5caa957291fb77d88d910e9801b2062bc02 (diff) | |
| download | NetworkManager-1e5206414af83ede1e4e1ff6f525161b83519845.tar.gz | |
device: don't delay startup complete for pending-actions "autoconf", "dhcp4" and "dhcp6"
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 extensively configurable (e.g. you cannot exclude devices from
being waited). However, the intent is to wait that all devices are "settled".
That means among others, that the timeouts waiting for carrier and Wi-Fi scan
results passed, and devices either don't have a connection profile to autoactivate,
or they autoactivated profiles and are in state "connected".
A major point here is that the device is considered ready, once it
reaches the state "connected". 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
device. So, it is wrong to have distinct pending actions for these operations.
Remove them.
This fixes that we wrongly would wait too long before declaring startup
complete. But it is also a change in behavior.
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 6 |
1 files changed, 6 insertions, 0 deletions
@@ -10,6 +10,12 @@ USE AT YOUR OWN RISK. NOT RECOMMENDED FOR PRODUCTION USE! * Drop support for BlueZ 4. BlueZ 5 was released in 2012 and should nowadays be available everywhere. +* core: declare "startup complete" when device reaches "connected" + state, even if IP addressing methods did not yet fully complete. + This changes behavior for unblocking "NetworkManager-wait-online.service", + and "network-online.target" earlier. If this causes issues in your + setup, you may need to configure "ipv4.may-fail=no" or "ipv6.may-fail=no", + which delays reaching "connected" state for the address family accordingly. * Various bug fixes and improvements. ============================================= |