[Bug 1442828] Re: change for LP 1425376 breaks systemd After=network-online.target

[Martin Pitt]

I suppose that merely reintroducing the Type=oneshot will make things
work again?

However, I don't really understand this yet. ifup at .service should have
nothing to do with how network-online.target behaves. For the record,
the design of this is as follows:

  * ifup at .service should not be depended on by anything, and it should
be possible to run this asynchronously. This job will bring up
hotplugged network interfaces during runtime, and the
Before=network.target will ensure that any consumer of network related
functionality will stop before any ifup at .service during shutdown. The
"network.target" is relatively uninteresting during bootup (there its
main function is to sort firewalls etc. before bringing up any network
interface via network-pre.target).

 * Coldplugged interfaces during boot, and virtual ones like bridges,
bonds, etc. will be brought up by /etc/init.d/networking (aka
networking.service). However, this is Type=forking, not oneshot, so will
(and should) run in parallel with everything else during boot.

 * With ifupdown (i. e. /etc/network/interfaces), the ifup-wait-all-
auto.service unit is supposed to wait for all interfaces to be "up", and
this implements network-online.target. This calls "ifquery --state
<interface>" to ask ifupdown whether an interface is up. So from your
bug report I conclude that this isn't actually working, and ifupdown
considers an interface as "up" even before dhclient finished?

It was, and would be wrong to make network.target having to wait for any
ifup at .service to finish again. This unnecessarily delays the boot and
causes too big hangs when any network interface is unavailable, like in
bug 1425376.

So if I understood this right, then asking ifquery --state in ifup-wait-
all-auto.service isn't sufficient, and this check needs to become
stronger?

To confirm this, would you mind attaching "journalctl -b" to this bug,
once for a boot with the current ifup at .service and once with reverting
back to Type=oneshot? I'd like to compare the startup order and DHCP
interaction there. Thanks!

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

** Package changed: systemd (Ubuntu) => ifupdown (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1442828

Title:
  change for LP 1425376 breaks systemd After=network-online.target

Status in ifupdown package in Ubuntu:
  New

Bug description:
  
  The change to ifup at .service done as part of LP 1425376 appears to break the ordering of units marked as "After=network-online.target".  In my specific case, a new service script with "After=network-online.target" is erroneously run concurrently with dhclient.  As the new script depends on networking configuration being complete, it fails as the IP addresses and routes from DHCP are not configured.  This functioned correctly on vivid daily images from a few days ago, and appears to break starting with the vivid daily from approximately 0409.

  Infinity suggested this change as a likely suspect:

  diff -Nru systemd-219/debian/extra/units/ifup at .service systemd-219/debian/extra/units/ifup at .service
  --- systemd-219/debian/extra/units/ifup at .service	2015-04-02 08:08:56.000000000 +0000
  +++ systemd-219/debian/extra/units/ifup at .service	2015-04-07 14:38:38.000000000 +0000
  @@ -6,10 +6,8 @@
   DefaultDependencies=no
   
   [Service]
  -Type=oneshot
  -ExecStart=/sbin/ifup --allow=hotplug %I
  -ExecStartPost=/sbin/ifup --allow=auto %I
   # only fail if ifupdown knows about the iface AND it's not up
  -ExecStartPost=/bin/sh -c 'if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi'
  +ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifup --allow=auto %I; \
  +    if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi'
   ExecStop=/sbin/ifdown %I
   RemainAfterExit=true

  and, indeed, reverting this (copying ifup at .service from a few-days old
  vivid image to a current image) resolves the problem.

  The affected version is  ubuntu-vivid-daily-amd64-server-20150409.2
  (installed via AWS).

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