Bug 612934 - NetworkManager or ifup script cannot handle interface correctly
NetworkManager or ifup script cannot handle interface correctly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: initscripts Maintenance Team
qe-baseos-daemons
:
: 628545 (view as bug list)
Depends On:
Blocks: 684385
  Show dependency treegraph
 
Reported: 2010-07-09 06:55 EDT by Stefan Assmann
Modified: 2011-05-19 09:51 EDT (History)
7 users (show)

See Also:
Fixed In Version: initscripts-9.03.18-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 09:51:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/sysconfig/network-scripts/ifcfg-eth0 (232 bytes, application/octet-stream)
2010-07-09 06:55 EDT, Stefan Assmann
no flags Details
ifdown: call nmcli for managed devices, ifdown-<devtype> for others (1.59 KB, patch)
2010-11-01 06:06 EDT, Jirka Klimes
no flags Details | Diff
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz (1023.38 KB, application/x-xz)
2010-12-07 14:46 EST, Joseph Kachuck
no flags Details
SOSReport (1.04 MB, application/octet-stream)
2011-03-26 12:04 EDT, IBM Bug Proxy
no flags Details
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz (100 bytes, application/octet-stream)
2011-03-26 12:05 EDT, IBM Bug Proxy
no flags Details
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz (752.60 KB, application/octet-stream)
2011-03-26 12:05 EDT, IBM Bug Proxy
no flags Details
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz (462.21 KB, application/octet-stream)
2011-03-26 12:05 EDT, IBM Bug Proxy
no flags Details
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz (166.23 KB, application/octet-stream)
2011-03-26 12:05 EDT, IBM Bug Proxy
no flags Details

  None (edit)
Description Stefan Assmann 2010-07-09 06:55:22 EDT
Created attachment 430638 [details]
/etc/sysconfig/network-scripts/ifcfg-eth0

Description of problem:
This is how the NIC looks like after booting
root@intel-sunriseridge-01.lab.bos.redhat.com:~> ifconfig
eth0      Link encap:Ethernet  HWaddr 00:13:20:F7:A5:9E  
          inet addr:10.16.42.238  Bcast:10.16.47.255  Mask:255.255.248.0
          inet6 addr: fe80::213:20ff:fef7:a59e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8669 errors:0 dropped:0 overruns:1 frame:0
          TX packets:235 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:841448 (821.7 KiB)  TX bytes:25807 (25.2 KiB)
          Memory:91a20000-91a40000 

root@intel-sunriseridge-01.lab.bos.redhat.com:~> ifdown eth0
Device state: 3 (disconnected)
root@intel-sunriseridge-01.lab.bos.redhat.com:~> ifup eth0

** (process:6487): WARNING **: fetch_connections_done: error fetching user connections: (2) The name org.freedesktop.NetworkManagerUserSettings was not provided by any .service files.
Error: Unknown connection: 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03.

Feel free to reassing if this is a problem of the ifup script.

Version-Release number of selected component (if applicable):
NetworkManager-glib-0.8.1-0.3.el6.x86_64
NetworkManager-gnome-0.8.1-0.3.el6.x86_64
NetworkManager-0.8.1-0.3.el6.x86_64

How reproducible:
always

Side note:
After "modprobe -r igb; modprobe igb" all interfaces appear in the ifconfig query, which means that the UP flag is set, which it was not before the reloading of the module. Any idea what's the reason for that?
Example:
root@intel-sunriseridge-01.lab.bos.redhat.com:~> ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:13:20:F7:A5:9F  
          BROADCAST MULTICAST  MTU:1500  Metric:1
[...]
root@intel-sunriseridge-01.lab.bos.redhat.com:~> modprobe -r igb ; modprobe igb
root@intel-sunriseridge-01.lab.bos.redhat.com:~> ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:13:20:F7:A5:9F  
          inet6 addr: fe80::213:20ff:fef7:a59f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

That interface does not have a cable connected.
Comment 2 Dan Williams 2010-07-12 18:19:28 EDT
When exactly does the NIC *not* have a cable attached?

But in any case, can you provide the results of this command?

dbus-send --system --print-reply --dest=com.redhat.ifcfgrh1 /com/redhat/ifcfgrh1 com.redhat.ifcfgrh1.GetIfcfgDetails string:"/etc/sysconfig/network-scripts/ifcfg-eth0"
Comment 3 Stefan Assmann 2010-07-13 03:05:03 EDT
sorry for the confusion. This is a quad-port NIC with the same configuration always:
eth0 cable connected
eth1 no cable
eth2 no cable
eth3 no cable

[root@intel-sunriseridge-01 ~]# dbus-send --system --print-reply --dest=com.redhat.ifcfgrh1 /com/redhat/ifcfgrh1 com.redhat.ifcfgrh1.GetIfcfgDetails string:"/etc/sysconfig/network-scripts/ifcfg-eth0"
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.redhat.ifcfgrh1 was not provided by any .service files
Comment 4 Dan Williams 2010-07-14 10:17:40 EDT
When you get that output to the command, can you check whether or not NetworkManager is actually running?

ps ax | grep Net

that response indicates that NM may not actually be running at the time.
Comment 5 RHEL Product and Program Management 2010-07-15 10:53:10 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 8 Jirka Klimes 2010-10-26 07:03:28 EDT
Thanks jkachuck for the clear steps to reproduce.

I think the problem is in ifdown script.
The first 'ifdown eth0' calls  'nmcli dev disconnect iface eth0', because the device is connected. However the second 'ifdown eth0' doesn't call that command. Instead it continues executing the script as if NM was not running, and calls 'ip link set dev eth0 down' that brings the link down. That's why next 'ifup eth0' is not successful within NM.

I'd suggest this change in /etc/sysconfig/network-scripts/ifdown:
if [ "$USE_NM" = "true" ]; then
    if [ -n "$UUID" -a -z "$DEVICE" ]; then
        DEVICE=$(nmcli -t --fields uuid,devices con status | awk -F ':' "\$1 == \"$UUID\" { print \$2 }")
    fi
-    if [ -n "$DEVICE" ] && is_nm_active "$DEVICE" ; then
+    if [ -n "$DEVICE" ] ; then
        nmcli dev disconnect iface "$DEVICE"
        exit $?
    fi
fi

'nmcli dev disconnect' will just return an error that the device is not active, but the link won't be down.
Comment 9 Issue Tracker 2010-10-27 13:07:20 EDT
Event posted on 10-26-2010 09:52pm EDT by Glen Johnson

------- Comment From qinzhl@cn.ibm.com 2010-10-26 21:47 EDT-------
(In reply to comment #22)
> Hello IBM,
> Please let me know if you would be able to test this to confirm it
corrects
> this issue.
>
> Thank You
> Joe Kachuck

Yes, It works. But  when will the 1st Rhel6 be released and this bug going
to be integrated into the 1st Rhel6 normal release?

And also we suggest that the error message for repeated ifdown can be
optimized.

Thanks.


This event sent from IssueTracker by jkachuck 
 issue 1482233
Comment 10 Jirka Klimes 2010-10-29 03:10:36 EDT
Bill, what do you think?
Comment 11 Bill Nottingham 2010-10-29 11:44:42 EDT
No, b/c that will cause errors on bonding, bridging, etc. devices that don't use NM but are present when NM is running.
Comment 12 Jirka Klimes 2010-11-01 06:06:16 EDT
Created attachment 456835 [details]
ifdown: call nmcli for managed devices, ifdown-<devtype> for others

Oh, you are right. That would break function for devices unmanaged by NM.
Nevertheless, we should call nmcli not only for connected devices, but for all managed devices. The attached patch should fix both cases.
Comment 15 Issue Tracker 2010-11-22 10:13:32 EST
Event posted on 11-21-2010 05:09am EST by Glen Johnson

File uploaded: sosreport-Rhel6.67694-20101020100436-0e14.tar.xz

This event sent from IssueTracker by jkachuck 
 issue 1482233
it_file 1161453
Comment 16 Laine Stump 2010-12-07 02:16:37 EST
*** Bug 628545 has been marked as a duplicate of this bug. ***
Comment 17 Joseph Kachuck 2010-12-07 14:46:16 EST
Created attachment 467288 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz
Comment 19 IBM Bug Proxy 2011-03-26 12:04:41 EDT
------- Comment From qinzhl@cn.ibm.com 2010-10-21 01:29 EDT-------
(In reply to comment #14)
> (In reply to comment #12)
> > Created an attachment (id=57148) [details] [details]
> > SOSReport
> Hi
>
> Thank you for providing sosreport. please provide the following as well.
>
> 1. Installation key used during installation.
> 2. Was the NetworkManager stopped, and network was started before doing any of
> this testing.
>
> Cheers,
> Prem

1. What do you mean by the installation key? I have no key typed on my installation. The ISO I use is from https://ftp3.linux.ibm.com/files/redhat/beta_cds

2. NO, I have verified that it is an issue of NetworkManager. When I stop NetworkManager and start network, everything goes well.

------- Comment From qinzhl@cn.ibm.com 2010-10-21 22:02 EDT-------
(In reply to comment #17)
> Hello,
> In the summery you noted  it works on Rhel6 Basic Server while failed on other
> Rhel6 Servers.
> Please provide more details on how to recreate this issue. Please confirm how
> you are doing the install.
>
>
> Status set to: Waiting on Client

1 Install Rhel6 Development Server (All other options is by default)
2 Input the following cmds and then you will find the problem(Here eth0 is already up):

ifdown eth0
ifdown eth0
ifup eth0

I have verified it's an issue of NetworkManager. Infact as long as you start the NetworkManager, the issue can be reproduced.

All of these info already mentioned on comments 4 and 15, why don't take a glance at the history records?

> Please let me know if you would be able to test this to confirm it corrects
>
> Thank You
> Joe Kachuck

Yes, It works. But  when will the 1st Rhel6 be released and this bug going to be integrated into the 1st Rhel6 normal release?

And also we suggest that the error message for repeated ifdown can be optimized.


------- Comment From prem.karat@linux.vnet.ibm.com 2011-01-07 02:51 EDT-------
Joe,

Can you confirm in which release this fix is going to be included?

Cheers,
Prem
Comment 20 IBM Bug Proxy 2011-03-26 12:04:57 EDT
Created attachment 487842 [details]
SOSReport


------- Comment (attachment only) From qinzhl@cn.ibm.com 2010-10-19 22:14 EDT-------
Comment 21 IBM Bug Proxy 2011-03-26 12:05:04 EDT
Created attachment 487843 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz
Comment 22 IBM Bug Proxy 2011-03-26 12:05:13 EDT
Created attachment 487844 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz
Comment 23 IBM Bug Proxy 2011-03-26 12:05:22 EDT
Created attachment 487845 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz
Comment 24 IBM Bug Proxy 2011-03-26 12:05:29 EDT
Created attachment 487846 [details]
sosreport-Rhel6.67694-20101020100436-0e14.tar.xz
Comment 26 errata-xmlrpc 2011-05-19 09:51:09 EDT
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-0647.html

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