Comment 19 for bug 1701023

Test case #1 (bug 1573272), part (a) and (b) only:

I'm unable to reproduce test case #1 failure on trusty, because upstart is used instead of systemd. I'm not sure if that means the race condition doesn't affect trusty, or if i'm just not able to properly introduce a upstart delay to bond0 to easily reproduce the problem. I did verify that the vlan pkg from my test ppa does not cause any regression for testcase 1(a) or 1(b) on trusty.

On Xenial, I verified vlan pkg 1.9-3.2ubuntu1.16.04.1 did fail, 1.9-3.2ubuntu1.16.04.4 did not fail, and my test pkg did not fail. I tested reboot (test 1a) and ifup -a (test 1b).

On Artful, I verified with 1.9-3.2ubuntu2 (failed as expected), 1.9-3.2ubuntu5 (worked as expected), and my ppa version (worked as expected). Again tested with reboot and ifup -a.

On Bionic, the vlan pkgs are the same as Artful; the same pkg versions behaved the same as Artful, as expected.

For test 1(c), hotplugging the bond slave interfaces - which I used module rmmod/modprobe to test - my change introduces failure for all releases. This is because I move the call to /lib/udev/vlan-network-interface into the if-up.d post-up scripts, and the ifquery call inside vlan-network-interface fails during that time because it claims it is a "recursive" call:

Apr 20 17:34:53 lp1701023-b sh[2588]: ifquery: recursion detected for interface bond0 in post-up phase
Apr 20 17:34:53 lp1701023-b sh[2588]: ifquery: recursion detected for parent interface bond0 in post-up phase

ifupdown seems broken in this manner; ifquery --list should not involve any "recursion" or locking, as it is simply reading the config files and listing all configured interfaces. It should not need to lock any interfaces, as it's not actually changing anything. So, I plan to continue with my design change and fix ifupdown as well.