Bug 669728 - ifdown hangs indefinitely when
Summary: ifdown hangs indefinitely when
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts
Version: 5.5
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-14 14:56 UTC by Magnus Glantz
Modified: 2018-11-30 20:08 UTC (History)
3 users (show)

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.
Clone Of:
Environment:
Last Closed: 2011-07-21 08:37:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1081 0 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2011-07-21 08:33:52 UTC

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


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