| 2016-05-03 16:02:18 |
Martin Pitt |
bug |
|
|
added bug |
| 2016-05-03 16:29:05 |
Martin Pitt |
description |
ifup@.service can (and often does) run for a particular interface before networking.service runs. This is brittle as during early boot ifup is prone to fail: / might still be read-only, /var might not yet exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might silently fail, etc. It is also unnecessary as networking.service will bring up all "auto" and all present "allow-hotplug" interfaces anyway, and it runs at the right time.
We should make either 80-ifupdown.rules or ifup@.service ignore events until networking.service is active, or wait until after it has run (slower, but avoids race conditions when hotplug events happen while networking.service is running). Ideally adding After=networking.service ought to suffice (need to check that activating the unit is properly postponed until after networking.service), or we need to do that waiting/ignoring in the ExecStart= shell code.
https://bugs.debian.org/752919 is related to this issue. |
ifup@.service can (and often does) run for a particular interface before networking.service runs. This is brittle as during early boot ifup is prone to fail: / might still be read-only, /var might not yet exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might silently fail, etc. It is also unnecessary as networking.service will bring up all "auto" and all present "allow-hotplug" interfaces anyway, and it runs at the right time.
We should make either 80-ifupdown.rules or ifup@.service ignore events until networking.service is active, or wait until after it has run (slower, but avoids race conditions when hotplug events happen while networking.service is running). Ideally adding After=networking.service ought to suffice (need to check that activating the unit is properly postponed until after networking.service), or we need to do that waiting/ignoring in the ExecStart= shell code.
This also affects cloud-init's setup of networking: this currently jumps through a lot of bad hoops to make sure that ifup@ does not run until after cloud-init-local.service. This includes blocking udev rules for an indefinite time, which is racy, a potential deadlock, and highly non-elegant.
https://bugs.debian.org/752919 is related to this issue. |
|
| 2016-05-03 16:29:19 |
Martin Pitt |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2016-05-03 16:32:39 |
Martin Pitt |
ifupdown (Ubuntu): status |
New |
In Progress |
|
| 2016-05-03 16:32:42 |
Martin Pitt |
ifupdown (Ubuntu): assignee |
|
Martin Pitt (pitti) |
|
| 2016-05-03 17:00:52 |
Martin Pitt |
description |
ifup@.service can (and often does) run for a particular interface before networking.service runs. This is brittle as during early boot ifup is prone to fail: / might still be read-only, /var might not yet exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might silently fail, etc. It is also unnecessary as networking.service will bring up all "auto" and all present "allow-hotplug" interfaces anyway, and it runs at the right time.
We should make either 80-ifupdown.rules or ifup@.service ignore events until networking.service is active, or wait until after it has run (slower, but avoids race conditions when hotplug events happen while networking.service is running). Ideally adding After=networking.service ought to suffice (need to check that activating the unit is properly postponed until after networking.service), or we need to do that waiting/ignoring in the ExecStart= shell code.
This also affects cloud-init's setup of networking: this currently jumps through a lot of bad hoops to make sure that ifup@ does not run until after cloud-init-local.service. This includes blocking udev rules for an indefinite time, which is racy, a potential deadlock, and highly non-elegant.
https://bugs.debian.org/752919 is related to this issue. |
ifup@.service can (and often does) run for a particular interface before networking.service runs. This is brittle as during early boot ifup is prone to fail: / might still be read-only, /var might not yet exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might silently fail, etc. It is also unnecessary as networking.service will bring up all "auto" and all present "allow-hotplug" interfaces anyway, and it runs at the right time.
We should make either 80-ifupdown.rules or ifup@.service ignore events until networking.service is active, or wait until after it has run (slower, but avoids race conditions when hotplug events happen while networking.service is running). Thus we need to add After=networking.service to ifup@.service, so that this only does stuff after doing the "coldplug" configuration.
This also affects cloud-init's setup of networking: this currently jumps through a lot of bad hoops to make sure that ifup@ does not run until after cloud-init-local.service. This includes blocking udev rules for an indefinite time, which is racy, a potential deadlock, and highly non-elegant.
https://bugs.debian.org/752919 is related to this issue. |
|
| 2016-05-03 20:27:29 |
Martin Pitt |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752919 |
|
| 2016-05-03 20:27:29 |
Martin Pitt |
bug task added |
|
ifupdown (Debian) |
|
| 2016-05-04 00:07:26 |
Bug Watch Updater |
ifupdown (Debian): status |
Unknown |
New |
|
| 2016-05-04 12:57:54 |
Martin Pitt |
bug task deleted |
ifupdown (Debian) |
|
|
| 2016-05-04 13:05:16 |
Martin Pitt |
ifupdown (Ubuntu): status |
In Progress |
Invalid |
|
| 2016-05-04 13:05:28 |
Martin Pitt |
cloud-init (Ubuntu): status |
New |
Triaged |
|
| 2016-05-04 13:05:56 |
Martin Pitt |
summary |
don't run ifup@.service before networking.service |
Drop unnecessary blocking of all net udev rules |
|
| 2016-05-04 13:07:51 |
Martin Pitt |
description |
ifup@.service can (and often does) run for a particular interface before networking.service runs. This is brittle as during early boot ifup is prone to fail: / might still be read-only, /var might not yet exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might silently fail, etc. It is also unnecessary as networking.service will bring up all "auto" and all present "allow-hotplug" interfaces anyway, and it runs at the right time.
We should make either 80-ifupdown.rules or ifup@.service ignore events until networking.service is active, or wait until after it has run (slower, but avoids race conditions when hotplug events happen while networking.service is running). Thus we need to add After=networking.service to ifup@.service, so that this only does stuff after doing the "coldplug" configuration.
This also affects cloud-init's setup of networking: this currently jumps through a lot of bad hoops to make sure that ifup@ does not run until after cloud-init-local.service. This includes blocking udev rules for an indefinite time, which is racy, a potential deadlock, and highly non-elegant.
https://bugs.debian.org/752919 is related to this issue. |
cloud-inits networking setup currently jumps through a lot of bad hoops to make sure that ifup@ does not run until after cloud-init-local.service. This includes blocking udev rules for an indefinite time, which is racy, a potential deadlock, and highly non-elegant.
This is also not necessary: while ifupdown's net udev rule certainly can fire before cloud-init-local, it only asynchronously starts ifup@.service which will be deferred until after network-pre.target and thus after cloud-init-local.service.
-------
Original description, which turned out to be completely false and just us being misled:
ifup@.service can (and often does) run for a particular interface before networking.service runs. This is brittle as during early boot ifup is prone to fail: / might still be read-only, /var might not yet exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might silently fail, etc. It is also unnecessary as networking.service will bring up all "auto" and all present "allow-hotplug" interfaces anyway, and it runs at the right time.
We should make either 80-ifupdown.rules or ifup@.service ignore events until networking.service is active, or wait until after it has run (slower, but avoids race conditions when hotplug events happen while networking.service is running). Thus we need to add After=networking.service to ifup@.service, so that this only does stuff after doing the "coldplug" configuration.
This also affects cloud-init's setup of networking: this currently jumps through a lot of bad hoops to make sure that ifup@ does not run until after cloud-init-local.service. This includes blocking udev rules for an indefinite time, which is racy, a potential deadlock, and highly non-elegant.
https://bugs.debian.org/752919 is related to this issue. |
|
| 2016-05-04 13:07:58 |
Martin Pitt |
cloud-init (Ubuntu): assignee |
|
Scott Moser (smoser) |
|
| 2016-05-04 13:08:09 |
Martin Pitt |
ifupdown (Ubuntu): assignee |
Martin Pitt (pitti) |
|
|
| 2016-05-04 17:28:26 |
Scott Moser |
attachment added |
|
unlink and relink script https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844/+attachment/4655826/+files/unlink-link-dev |
|
| 2016-05-09 18:44:53 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-05-27 21:04:38 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/cloud-init/trunk.fix-networking |
|
| 2016-06-02 00:52:42 |
Scott Moser |
bug task deleted |
ifupdown (Ubuntu) |
|
|
| 2016-06-03 13:30:59 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2016-06-03 20:22:35 |
Launchpad Janitor |
branch linked |
|
lp:cloud-init |
|
| 2016-06-05 02:01:23 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
Triaged |
Fix Released |
|
| 2016-06-06 13:33:11 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/ubuntu/yakkety/cloud-init/pkg |
|
| 2016-06-22 20:09:16 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/ubuntu/xenial/cloud-init/pkg |
|
| 2016-06-23 18:59:16 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-06-23 18:59:16 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2016-06-23 18:59:30 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2016-06-23 18:59:30 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-06-23 18:59:39 |
Scott Moser |
cloud-init (Ubuntu Xenial): assignee |
|
Scott Moser (smoser) |
|
| 2016-07-11 15:58:05 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
In Progress |
Fix Released |
|
