fix ifupdown deadlocking against itself
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ifupdown (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Trusty |
New
|
Undecided
|
Unassigned |
Bug Description
Hi,
First of all, thanks a lot for all the work going into Ubuntu!
While setting up a new StorPool customer installation on a 14.04 LTS server, I configured a VLAN on a physical Ethernet interface and then, separately, a bond interface that contains the Ethernet interface. When I tried to reboot the machine, it hung while trying to bring the network interfaces down.
I tracked it down to a problem in the way the hierarchical interface locking was backported from Debian's ifupdown two years ago: a VLAN parent interface is locked, but then only unlocked at the end of the function, and not at the end of the per-interface loop (in Debian's ifupdown, the per-interface handling is in a separate function, so the parent interface is unlocked at the correct time). This leads to problems when another interface specified on the command line (or deduced if the -a option is used) has scripts that run ifdown on the still-locked parent interface.
I've attached a trivial patch that should correct the issue. It may be tested on e.g. a virtual machine with the following interface configuration:
auto ens9
iface ens9 inet manual
bond-master bond0
bond-primary ens9
auto ens9.200
iface ens9.200 inet static
address 192.168.192.1/28
vlan-raw-device ens9
auto ens10
iface ens10 inet manual
bond-master bond0
auto bond0
iface bond0 inet static
address 192.168.13.2/24
bond-mode active-backup
bond_arp_ip_target 192.168.13.4
bond_arp_interval 200
bond-slaves none
With this configuration, execute the following commands:
ifup ens9.200
ifup bond0
ifdown ens9.200 bond0
The last command will cause ifdown to forget to unlock the ens9 interface, then invoke ifenslave's script to bring down the bond interface's physical components, which will spawn a second "ifdown ens9" which will wait forever for its parent to drop the leaked lock.
Thanks in advance for your time, and keep up the great work!
Best regards,
Peter
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ifupdown 0.7.47.2ubuntu4.4
ProcVersionSign
Uname: Linux 3.13.0-133-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.25
Architecture: amd64
Date: Wed Oct 18 09:45:27 2017
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ifupdown
UpgradeStatus: No upgrade log present (probably fresh install)
Just for the record, while I do agree that this is a rare and unusual setup, it is nevertheless a perfectly valid one and there's no reason for it not to be supported.
Also, I just checked both the source and the actual behavior of the ifupdown package in 16.04 and it's fine - the locking of the parent interface is done in the do_interface() function and it's unlocked at the end.
Best regards,
Peter