Adding cloud-init task as once we fix ifup@.service we can drop the udev rule blocking.
** Description changed: 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. ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: ifupdown (Ubuntu) Status: New => In Progress ** Changed in: ifupdown (Ubuntu) Assignee: (unassigned) => Martin Pitt (pitti) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1577844 Title: don't run ifup@.service before networking.service Status in cloud-init package in Ubuntu: New Status in ifupdown package in Ubuntu: In Progress Bug 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
