Bug 1311811 - ifdown on lo alias does not work
ifdown on lo alias does not work
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts (Show other bugs)
x86_64 Linux
urgent Severity urgent
: rc
: ---
Assigned To: David Kaspar [Dee'Kej]
Jan Ščotka
Mirek Jahoda
: FastFix, Patch, Reproducer, ZStream
Depends On:
Blocks: 1269194 1356056 1359260 1370193 1398678 1420052 1420053
  Show dependency treegraph
Reported: 2016-02-24 22:43 EST by Jonathan Maxwell
Modified: 2017-03-21 07:52 EDT (History)
9 users (show)

See Also:
Fixed In Version: initscripts-9.03.54-1
Doc Type: Bug Fix
Doc Text:
"ifdown" on a loopback device now works properly In Red Hat Enterprise Linux version 6.7 and 6.8, executing the "ifdown" command on a local loopback device failed to remove the device. A patch has been applied, and the removal of an existing loopback device using "ifdown" now succeeds.
Story Points: ---
Clone Of:
: 1398678 1420052 1420053 (view as bug list)
Last Closed: 2017-03-21 07:52:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2327451 None None None 2016-05-17 13:54 EDT

  None (edit)
Description Jonathan Maxwell 2016-02-24 22:43:36 EST
Description of problem:

when executing ifdown lo:0, it does not report an error but fails to remove the device.

This worked on RHEL6.6 but fails on RHEL6.7. Replacing RHEL6.7 /etc/sysconfig/ifdown-eth with a RHEL6.6 fixed the problem.

Version-Release number of selected component (if applicable):


# rpm -qa |grep initscr

How reproducible:

Steps to Reproduce:
1. Install RHEL6.7 and make sure above initscript version is installed.
2. Create the following /etc/sysconfig/network-scripts/ifcfg-lo:0 file:


3. Bring the device up:

# ifup lo:0

4. Now ifdown:

# ifdown lo:0

The device is still there:

# ifconfig
lo:0      Link encap:Local Loopback  
          inet addr:  Mask:
          UP LOOPBACK RUNNING NOARP  MTU:65536  Metric:1

Actual results:

The lo:0 device is not removed.

Expected results:

The lo:0 device should be removed.

Additional info:

I add the following patch:


However the problem remained. 

Then I changed the following:

if [ "${REALDEVICE}" = "lo" ]; then
       ip addr flush dev ${REALDEVICE} ${LABEL} scope host 2>/dev/null


ip addr flush dev ${REALDEVICE} ${LABEL} scope global 2>/dev/null

Here is the diff:

# diff -Naur /etc/sysconfig/network-scripts/ifdown-eth ifdown-eth.fix
--- /etc/sysconfig/network-scripts/ifdown-eth	2016-02-24 22:35:42.092750956 -0500
+++ ifdown-eth.fix	2016-02-24 22:35:07.495844305 -0500
@@ -111,7 +111,7 @@
 		LABEL="label ${DEVICE}"
 	if [ "${REALDEVICE}" = "lo" ]; then
-		ip addr flush dev ${REALDEVICE} ${LABEL} scope host 2>/dev/null
+		ip addr flush dev ${REALDEVICE} ${LABEL} scope global 2>/dev/null
 		ip addr flush dev ${REALDEVICE} ${LABEL} scope global 2>/dev/null
 		ip -4 addr flush dev ${REALDEVICE} ${LABEL} scope host 2>/dev/null

and that fixed the problem.
Comment 2 Lukáš Nykrýn 2016-02-25 04:27:01 EST
Unfortunately running flush on lo devices with scope global brings other problems
Comment 3 Jonathan Maxwell 2016-02-25 16:53:35 EST
I wonder why flushing lo with global hangs in the bz_1072967 case? I don't see that behaviour on my LAB system. It shutdowns and boots up fine with this change.
Comment 13 Lukáš Nykrýn 2016-06-30 01:44:51 EDT
"fixed" in upstream rhel6 branch -> https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel6-branch&id=d59202d1d37c23126e17f8bc05d8a05d059b72a0 -> post
Comment 14 Ashish Vijayaram 2016-08-22 14:51:06 EDT
This bug is present in CentOS 7 as well - https://bugs.centos.org/view.php?id=10980. Can the upstream fix be ported over for the rhel7-branch as well?
Comment 15 Ashish Vijayaram 2016-08-22 14:56:27 EDT
Apologies, ignore Comment 14.
Comment 17 David Kaspar [Dee'Kej] 2016-11-07 09:03:32 EST
Commit was accepted:
Comment 26 errata-xmlrpc 2017-03-21 07:52:32 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.