Public bug reported: 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. ** Affects: ifupdown (Ubuntu) Importance: Undecided Status: New -- 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 ifupdown package in Ubuntu: New 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. 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 -- 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
