fix ifupdown deadlocking against itself

Bug #1724523 reported by Peter Pentchev
8
This bug affects 1 person
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
ProcVersionSignature: User Name 3.13.0-133.182-generic 3.13.11-ckt39
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_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ifupdown
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Peter Pentchev (roam-ringlet) wrote :
Revision history for this message
Peter Pentchev (roam-ringlet) wrote :

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

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Do not leak the parent interface's lock." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

This setup is not that unusual, in a server/data-centre environment.

do not that current ubuntu LTS release is 16.04 LTS, and one may wish to migrate to that. And soon 18.04 LTS will be available. This is just an FYI, I guess you have reasons for sticking on 14.04, but I do wish people move on to newer and more secure Ubuntu releases =)))))

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.