Bug 669728

Summary:	ifdown hangs indefinitely when
Product:	Red Hat Enterprise Linux 5	Reporter:	Magnus Glantz <mglantz>
Component:	initscripts	Assignee:	initscripts Maintenance Team <initscripts-maint-list>
Status:	CLOSED ERRATA	QA Contact:	qe-baseos-daemons
Severity:	high	Docs Contact:
Priority:	low
Version:	5.5	CC:	azelinka, harald, notting
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Previously, when MAC (Media Access Control) addresses were switched on a virtual machine or a physical machine with two network interfaces, the /sbin/ifdown script became unresponsive when the network was restarted. With this update, the script recognices that the MAC address for the network interface is wrong and then ignores it, fixing this bug.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-21 08:37:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Magnus Glantz 2011-01-14 14:56:34 UTC

Description of problem:
/sbin/ifdown hangs indefinitely when mac-address of two interfaces switch.


Version-Release number of selected component (if applicable):
RHEL 5.5 latest updates.


How reproducible:
On a virtual machine or a physical machine with two network interfaces (eth0, eth1) put the mac-address of eth0 on eth1 and vice-versa. Then restart the network.


Steps to Reproduce:
1. Copy mac-address from /etc/sysconfig/network-scripts/ifcfg-eth0 to /etc/sysconfig/network-scripts/ifcfg-eth1 hash off the orginal mac-address
2. Copy mac-address from /etc/sysconfig/network-scripts/ifcfg-eth1 to /etc/sysconfig/network-scripts/ifcfg-eth0 hash off the orginal mac-address 
3. Run: /sbin/ifdown eth0 or /sbin/ifdown eth1
  
Actual results:
/sbin/ifdown hangs indefinitely

Expected results:
/sbin/ifdown recognices that the mac-address for the network interface is wrong, and it then ignores it. This is what happens if you just change the mac-address of an interace to an mac-address that does not exist on any other network interface on your server.

Additional info:
This can be a blocking issue for fully automatic systems, where a system cannot hang indefinitely.

Comment 2 Bill Nottingham 2011-01-14 17:06:33 UTC

See 1b9d3b70ea03346b9ffd4f024239f420ff61aaf8 and 4822a7a38eb42fb77ef36c25c0eae1c85e0154ab in git; this sounds an awful lot like bug 390271, which has not been backported to RHEL 5.

Comment 3 Magnus Glantz 2011-01-15 00:15:23 UTC

Indeed, I do see a loop.
And.. yes, that's it.

# ifdown eth1
Device eth0 has MAC address 52:54:00:2C:28:4A, instead of configured address 52:54:00:DE:06:14. Ignoring.
# ifup eth1
Device eth1 has different MAC address than expected, ignoring.

# service network restart
Shutting down interface eth0:  Device eth1 has MAC address 52:54:00:DE:06:14, instead of configured address 52:54:00:2C:28:4A. Ignoring.
                                                           [FAILED]
Shutting down interface eth1:  Device eth0 has MAC address 52:54:00:2C:28:4A, instead of configured address 52:54:00:DE:06:14. Ignoring.
                                                           [FAILED]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  Device eth0 has different MAC address than expected, ignoring.
                                                           [FAILED]
Bringing up interface eth1:  Device eth1 has different MAC address than expected, ignoring.
                                                           [FAILED]

*** This bug has been marked as a duplicate of bug 390271 ***

Comment 4 Bill Nottingham 2011-01-17 16:11:22 UTC

Reopening on the assumption that you may want this fixed in RHEL 5.

Comment 5 Magnus Glantz 2011-01-18 09:09:03 UTC

Correct, thank you :-)

Comment 6 RHEL Program Management 2011-02-01 17:01:23 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 10 Tomas Capek 2011-07-13 12:29:42 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, when MAC (Media Access Control) addresses were switched on a virtual machine or a physical machine with two network interfaces, the /sbin/ifdown script became unresponsive when the network was restarted. With this update, the script recognices that the MAC address for the network interface is wrong and then ignores it, fixing this bug.

Comment 11 errata-xmlrpc 2011-07-21 08:37:22 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1081.html

Comment 12 errata-xmlrpc 2011-07-21 12:40:22 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1081.html