The fixes in vlan package are insufficient, as networking.service spawns ifup@.services in parallel with no ordering information and therefore systemd is free to process them in a racy manner. At boot ifup@.services are racing with networking.service and can result in a deadlock as you have experienced.
@tom-verdaat To resolve boot time races, you need to provide manual dependency ordering of the ifup@.service systemd units, as at the moment, unfortunately, these are not automatically generated. For you pasted config I believe you require the following files: # cat /etc/systemd/system/ifup@bond1.2.service.d/order.conf [Unit] Wants=ifup@bond1.service After=ifup@bond1.service # cat /etc/systemd/system/ifup@bond1.service.d/order.conf [Unit] Wants=ifup@eno1.service Wants=ifup@eno2.service After=ifup@eno1.service After=ifup@eno2.service In 17.10 and later releases these races are fixed with netplan. netplan is also available and can be used on xenial. netplan generates correct configuration and then all of bonds/vlans are managed by networkd in a race-free manner. I apologize for the inconvenience =( -- 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/1636708 Title: ifup -a does not start dependants last, causes deadlocks with vlans/bonding Status in ifupdown package in Ubuntu: Confirmed Status in ifupdown source package in Xenial: Confirmed Bug description: This is a problem I've been struggling with since moving to 16.04.1 from 14.04 (fresh install) I don't believe this problem affected 14.04. I have used an almost identical interfaces file on 14.04 without problem. On 16.04.1, however, 9/10 boots would hang during network configuration and leave the network incorrectly configured. When calling "ifup -a" all candidate interfaces appear to be started in parallel leading to collisions with locks. This causes hanging (until timeout) during booting and the network interfaces left incorrectly configured Imagine this /etc/network/interfaces auto eno1 bond0 bond0.1 iface eno1 inet manual bond-master bond0 iface bond0 inet manual bond-slaves eno1 bond-mode 4 bond-lacp-rate 1 bond-miimon 100 bond-updelay 200 bond-downdelay 200 iface bond0.5 inet dhcp vlan-raw-device bond0 eno1 -> bond0 -> bond0.5 -> dhcp When calling "ifup -a" at boot time all three interfaces are started at the same time. bond0 and bond0.5 both attempt to share the same lock file: /run/network/ifstate.bond0 If bond0 wins the race, the system will start correctly (1/10): * bond0 starts and creates the bond0 device and the ifenslave.bond0 file to indicate the bond is ready * eno1 polls for the ifenslave.bond0 file, when it appears it attaches eno1 to bond0 * bond0 finishes and releases the lock * bond0.5 now acquires the lock. * bond0.5 starts dhclient, which can talk to the network and configure the interface If, however, bond0.2 wins the lock race, the system will hang at boot (5 mins) and fail to set up the network. * bond0.5 is awarded the ifstate.bond0 lockfile * bond0.5 starts dhclient waiting to hear from the network * bond0 is blocked, so bond0 is not created nor is the bond0.ifenslave file * eno1 polls but never finds the ifenslave.bond0 file so never attaches to bond0 * bond0.5's dhclient is trying to talk to a disconnected network and never receives an answer ! bond0.5 is stuck running dhclient ! bond0 is stuck waiting for bond0.5 to finish ! eno1 is stuck waiting for bond0 to create the ifenslave.bond0 file I believe ifup should start interfaces (that share lock files) in dependant order. The most basic interface must be awarded the lock over its dependants. In this case: 1 eno1 2 bond0 3 bond0.5 but never: 1 eno1 2 bond0.5 3 bond0 As a work arouund, in /etc/network/interfaces -auto eno1 bond0 bond0.1 +auto eno1 bond0 +allow-bond bond0.1 And also in /lib/systemd/system/networking.service ExecStart=/sbin/ifup -a --read-environment +ExecStart=/sbin/ifup -a --allow=bond --read-environment ExecStop=/sbin/ifdown -a --read-environment Then run: systemctl dameon-reload This causes all "auto" interfaces to start then, when they've completed, all allow-bond interfaces to start. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ifupdown 0.8.10ubuntu1.1 [modified: lib/systemd/system/networking.service] ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21 Uname: Linux 4.4.0-45-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Wed Oct 26 06:32:57 2016 InstallationDate: Installed on 2016-10-24 (1 days ago) InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: ifupdown UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.init.networking.conf: [modified] mtime.conffile..etc.init.networking.conf: 2016-10-26T04:52:05.750927 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1636708/+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
