I would chime in a bit on this too. 14.04 _did_ have such issues. In
fact, I had a physical box with static IP's (2 nics), if a cable was
unpligged, it would hang forever and also become inconsistent. I had
these discussions a year ago or so. Anyway, I had ot abandon ubuntu
server (along with some nft issues at the time) and run archlinux as my
xen host.

But I ran zfs as my xen backend, so on arch, I sometimes* could have
issues ~ once a year where it best be I had physical access to the box
to be able to fix any potential issues.

I am now going to move abroad and so I thought , with archlinux unpriv.
lxc containers out, to leave xen (as I don't have the expected network
output from the servers) to lxc. With arch and benig abroad, I think
ubuntu 16.04 now with systemd would have solved this (my server with
arch on xen has always gracefully sorted it out: ~1.5-2 years).

Seeing this bug and seein git has to do with ifup makes me think it's
partly a remnance from the older logic from sysv/upstart.

This probably doesn't help much butjust saying the ifup is a bit archaic
now that systemd is in use and is not evebn present in archlinux and
creates seemingly less problems.

I have only a brief moment before leaving so seeing this now worries me.

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.

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

Status in ifupdown package in Ubuntu:

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

    Installed: 229-4ubuntu6
    Candidate: 229-4ubuntu6
    Version table:
   *** 229-4ubuntu6 500
          500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
          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 
  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.


To manage notifications about this bug go to:

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

Reply via email to