[Bug 1577844] Re: don't run ifup at .service before networking.service
Martin Pitt
martin.pitt at ubuntu.com
Tue May 3 17:00:52 UTC 2016
** Description changed:
ifup at .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 at .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.
+ networking.service is running). Thus we need to add
+ After=networking.service to ifup at .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.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1577844
Title:
don't run ifup at .service before networking.service
Status in cloud-init package in Ubuntu:
New
Status in ifupdown package in Ubuntu:
In Progress
Bug description:
ifup at .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 at .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 at .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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844/+subscriptions
More information about the foundations-bugs
mailing list