Commit graph

3 commits

Author SHA1 Message Date
Waldemar Znoinski
4b222b8263 fix systemd resource deadlock
Dependency to start network-pre (which
depends on network.target) before
dhcp-interface@.service collides with
Ubuntu's own network.target that suupose
to start after network-pre.

Change-Id: I9e59c970bfb1ebdaa15b4ec6b545761ede3ca056
Closes-bug: #1619816
2016-09-06 04:47:29 +00:00
Sam Betts
eb99fe7144 Add dhcp-all-interfaces.target for syncing units
Currently there is no way for a service to become aware that
dhcp-all-interfaces is finished configuring all the interfaces at
boot time. This causes problems for applications like the
ironic-python-agent which scans the interfaces when it first starts as
part of the inspection stage and can race against dhcp-all-interfaces
bringing up the interfaces, leading to inconsistent results.

This patch ensures that the dhcp-all-interfaces script runs before any
network interface is configured and brought up by the rest of the
system, and also ensures that the ironic-agent element also waits for
the network to be online before starting. This is done by using the
network targets provided by systemd.

Change-Id: Id9583b7f54361aa603a6229da598ad6a0f0f7938
2016-05-16 10:15:53 +01:00
Dan Prince
00d853e5fd 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 14:33:14 -04:00