5bed4a6d5e
When we configure dhcp interfaces before network.target has run, network.target will try to bring up those interfaces a second time after our service does so. This causes two issues - first, the network target will always fail because it can't bring up an interface that is already up, and second, when configuring interfaces that don't actually have an available DHCP server it will result in a five minute delay waiting for DHCP on those interfaces. This will also cause the network target to fail and is an unnecessary delay. By moving the dhcp-interface service to run after the network target we avoid both of these problems. network.target will still bring up the interfaces on subsequent boots. This could result in the five minute delay happening on reboots, but the expected use case for interfaces without DHCP is that they would be configured statically on initial deployment so this should be a minor issue. The dhcp-interface service is also configured to run before the network-online target so that services which depend on the network actually being available will not race the DHCP process. A snippet from /var/log/messages on a node with this patch applied is included in the bug to demonstrate the behavior described above. Change-Id: I5cfabf20f920beea52abf4c42362b6f6ac0b37c4 Closes-Bug: 1653812 |
||
|---|---|---|
| .. | ||
| 50-dhcp-all-interfaces | ||
| 60-remove-cloud-image-interfaces | ||
| dhcp-all-interfaces-udev.rules | ||
| dhcp-all-interfaces.conf | ||
| dhcp-all-interfaces.init | ||
| dhcp-all-interfaces.sh | ||
| dhcp-interface@.service | ||