[Bug 1588915] Re: ifup does not block for interface to be up with static addresses

Tue Aug 16 23:54:01 UTC 2016

I am also affected by this issue. In my case both network.target and
network-online.target are reached too early, which results in sssd and
autofs to start before network interfaces are up; autofs then fails to
obtain mount maps and does not attempt to retry; it is necessary to
restart autofs manually after network has started fully.

Similarly as the bug reporter, I run Ubuntu 16.04 server, and I use
static addresses only, configured in /etc/network/interfaces.

The root cause is ifup exiting with success before network interfaces
start operating. However, ifup behaved the same way in Ubuntu 14.04, and
there it did not cause the problem. Apparently Upstart and its network-
related units were able to deal with this issue correctly. In contrast,
systemd configuration files packaged in ifupdown Xenial package are
causing the "async" behavior of ifup to surface and create problems.

During system boot there are two attempts to start physical network
interfaces by ifup: in ifup at .service (one service per interface) and in
networking.service. All these services start in parallel and call ifup
in parallel, but ifup uses a lock to prevent its concurrent execution
(per interface), effectively serializing ifup at .service(s) and
networking.service. In my tests, ifup@ services always win this race.
This actually works fine if all interfaces are configured successfully.
If not, networking.service performs a second attempt after ifup at .service
failed, which may be problematic (see below).

Targets network.target and network-online.target are reached when
networking.service finishes. This happens after interfaces are
configured by ifup. Interfaces became operable significantly later.

The problem may be worked around in a particular configuration in
several ways:

1. We can make ifup wait for the interface to come up, for example by
including a loop in post-up command in /etc/network/interfaces, checking
/sys/class/net/$INTERFACE/operstate. This would require using some
timeout, after which the command would fail, to deal with situations
such as a disconnected cable. In such a case, the delay would be twice
as long as the specified timeout, because that timeout will have to be
reached in both ifup at .service and networking service. If we do not
configure any virtual interfaces, we can deal with this by disabling
networking.service.

2. We can modify ifup at .service to wait for the interface to come up,
similarly as above. It will also be necessary to change the type of this
service from "simple" to "oneshot", to make it wait for its ExecStart
command before exiting.

3. We can also modify networking.service to wait in a similar manner.

4. We can introduce an additional service which will wait for all or
some interfaces to come up, and will delay network.target and network-
online.target until it is done. It would be advantageous to wait on all
interfaces in parallel, and I am not sure if that would be easy to
implement in one service.

5. An active waiting in a loop is obviously not the most beautiful
solution, so perhaps a cleaner way could be found?

-- 
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/1588915

Title:
  ifup does not block for interface to be up with static addresses

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  Description:    Ubuntu 16.04 LTS (server)
  Release:        16.04

  systemd:
    Installed: 229-4ubuntu6
    Candidate: 229-4ubuntu6
    Version table:
   *** 229-4ubuntu6 500
          500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
          100 /var/lib/dpkg/status
       229-4ubuntu4 500
          500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  This issue is more about systemd integration then an issue with
  systemd package itself.  The general problem is the distinction
  between the network being configured and the network being up and what
  that means for services that depend on the network.

  upstream systemd has network.target (network is configured) and
  network-online.target (network is up), however xenial server (dunno
  about desktop) doesn't seem to use network-online.target.  The result
  of which is, as soon as the network is configured both network.target
  and network-online.target are considered complete.  At which point
  services dependent on either of those will get started.  However this
  can lead to problems if the services in question are actually
  dependent on the network (ie dns lookups) when they are starting up.

  Here's an example of what I mean.  If you install openntpd and add the
  -s option there is a race on boot if it will or wont be able to do the
  initial sync.

  Jun 02 16:58:02 xenial64 systemd[1]: Reached target Network.
  Jun 02 16:58:02 xenial64 systemd[1]: Starting OpenNTPd Network Time Protocol...
  Jun 02 16:58:02 xenial64 systemd[1]: Reached target Network is Online.
  Jun 02 16:58:02 xenial64 ntpd[920]: constraint certificate verification turned off
  Jun 02 16:58:02 xenial64 ntpd[928]: ntp engine ready
  Jun 02 16:58:02 xenial64 kernel: tg3 0000:02:00.0 enp2s0: Link is down
  Jun 02 16:58:05 xenial64 kernel: tg3 0000:02:00.0 enp2s0: Link is up at 1000 Mbps, full duplex
  Jun 02 16:58:05 xenial64 kernel: tg3 0000:02:00.0 enp2s0: Flow control is on for TX and on for RX
  Jun 02 16:58:05 xenial64 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
  Jun 02 16:58:17 xenial64 ntpd[920]: no reply received in time, skipping initial time setting

  openntpd was started 3 seconds before the interface even got link.

  I believe this issue is only going to effect physical servers with
  static ips.  vm's interfaces will instantly have link when they are
  brought up and dhcp, the interface will already be up or else they
  wouldn't have been able to get an ip.

  thanks
  jim

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