sig_cloud/diskimage-builder
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0e700b25dc
diskimage-builder/diskimage_builder/elements/dhcp-all-interfaces/install.d/dhcp-interface@.service

26 lines
754 B
SYSTEMD
Raw Normal View History

DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803
2014-03-19 18:33:14 +00:00
[Unit]
Use %i instead of %I in dhcp-interface@.service Per the bug report, %I results in -'s in the interface name being replaced with /'s, which means when we try to look up the interface by path in dhcp-all-interfaces.sh we end up at an invalid path. Using %i instead should fix the problem. See https://www.freedesktop.org/software/systemd/man/systemd.unit.html Essentially what is happening is that we start with a name like br-ex that wasn't escaped in the first place. However, because of the - it looks like it could have been escaped to systemd. When we use %I, which tries to unescape escaped values, it unescapes a value that was already not escaped. Change-Id: I434ed2e084d4477dc7a2b7827164586f8ea0c1e3 Closes-Bug: 1649409
2016-12-12 21:46:25 +00:00
Description=DHCP interface %i
Run dhcp-interface@.service after network.target 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
2017-01-04 16:49:59 +00:00
# We want to run after network.target so it doesn't try to bring
# up the interfaces a second time, but network-online should not
# be reached until after we've brought up the interfaces.
Fix cylical systemd config for dhcp-all-interfaces In Ubuntu/Debian, the default dependencies cannot be relied upon as we enter into a cyclical dependency relationship which prevents the unit from starting. Added the required configuration to the systemd unit file. This issue has also been observed in glean[0], which has a nearly identical unit file for interface start-up. [0]: https://review.openstack.org/#/c/485748 Closes-Bug: #1708685 Change-Id: I23ac9510d1a21c7073bd33f76ba66fa04a8be035
2017-08-04 16:07:43 +00:00
# We also need to break the default dependencies which prevents
# this from operating on Ubuntu/Debian as the unit gets stuck
# into a cyclical dependency loop.
DefaultDependencies=no
Run dhcp-interface@.service after network.target 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
2017-01-04 16:49:59 +00:00
After=network.target
Before=network-online.target
Wants=network-online.target
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803
2014-03-19 18:33:14 +00:00
Use %i instead of %I in dhcp-interface@.service Per the bug report, %I results in -'s in the interface name being replaced with /'s, which means when we try to look up the interface by path in dhcp-all-interfaces.sh we end up at an invalid path. Using %i instead should fix the problem. See https://www.freedesktop.org/software/systemd/man/systemd.unit.html Essentially what is happening is that we start with a name like br-ex that wasn't escaped in the first place. However, because of the - it looks like it could have been escaped to systemd. When we use %I, which tries to unescape escaped values, it unescapes a value that was already not escaped. Change-Id: I434ed2e084d4477dc7a2b7827164586f8ea0c1e3 Closes-Bug: 1649409
2016-12-12 21:46:25 +00:00
ConditionPathExists=!/etc/sysconfig/network-scripts/ifcfg-%i
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803
2014-03-19 18:33:14 +00:00
[Service]
Type=oneshot
User=root
Use %i instead of %I in dhcp-interface@.service Per the bug report, %I results in -'s in the interface name being replaced with /'s, which means when we try to look up the interface by path in dhcp-all-interfaces.sh we end up at an invalid path. Using %i instead should fix the problem. See https://www.freedesktop.org/software/systemd/man/systemd.unit.html Essentially what is happening is that we start with a name like br-ex that wasn't escaped in the first place. However, because of the - it looks like it could have been escaped to systemd. When we use %I, which tries to unescape escaped values, it unescapes a value that was already not escaped. Change-Id: I434ed2e084d4477dc7a2b7827164586f8ea0c1e3 Closes-Bug: 1649409
2016-12-12 21:46:25 +00:00
ExecStartPre=/usr/local/sbin/dhcp-all-interfaces.sh %i
ExecStart=/sbin/ifup %i
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803
2014-03-19 18:33:14 +00:00
RemainAfterExit=true
Make DHCP timeout configurable As noted in the bug, there may be circumstances where a longer timeout than the current default is needed. This patch allows users to tune this timeout for their environment if need be. Change-Id: I173f3dad684894fbc3c27dece5ae15b5f63bae5a Closes-Bug: 1654027
2017-01-04 17:21:03 +00:00
TimeoutStartSec=DIB_DHCP_TIMEOUT
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803
2014-03-19 18:33:14 +00:00
[Install]
WantedBy=multi-user.target
Reference in New Issue Copy Permalink