[Bug 1577844] [NEW] don't run ifup at .service before networking.service

Martin Pitt martin.pitt at ubuntu.com
Tue May 3 16:02:18 UTC 2016


Public bug reported:

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.


https://bugs.debian.org/752919 is related to this issue.

** Affects: ifupdown (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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 ifupdown package in Ubuntu:
  New

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). 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1577844/+subscriptions



More information about the foundations-bugs mailing list