RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 888329 - Initscripts should ask NetworkManager if it is managing an interface
Summary: Initscripts should ask NetworkManager if it is managing an interface
Keywords:
Status: CLOSED DUPLICATE of bug 824130
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: NetworkManager
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Dan Williams
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-18 14:05 UTC by Antoni Segura Puimedon
Modified: 2014-12-08 00:50 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-25 23:32:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Antoni Segura Puimedon 2012-12-18 14:05:31 UTC 
Description of problem:
initscripts is able to use NetworkManager's nmcli to ifup and ifdown interfaces. To decide whether NM or plain initscripts flow is used, initscripts checks the existence and value of NM_CONTROLLED.

The problem with that is that NM_CONTROLLED=no by itself does not mean that the interface will not be managed by NetworkManager. For example, if HWADDR is missing from ifcfg, the interface will be managed by NM in any case.

The best way to know for sure if NM is controlling a device is asking it via DBUS.

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


How reproducible: 100%


Steps to Reproduce:
1. Create an ifcfg with NM_CONTROLLED=no and no HWADDR field
2. execute ifup
  
Actual results:
ifup does not use nmcli

Expected results:
ifup should use nmcli since NM states that the interface is managed.

Additional info:
The proposed flow for initscripts would be:

#Get the string em1 substituted by $1
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetDeviceByIpIface string:"em1"

#Substitute "/org/freedesktop/NetworkManager/Devices/1" with the objpath returned by the previous command.
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/1 org.freedesktop.DBus.Properties.Get string:"org.freedesktop.NetworkManager.Device" string:"state"

# use NM for ifup or ifdown if and only if the state returned by the previous command is different than 10 (which in NM means unmanaged).
Comment 1 Antoni Segura Puimedon 2012-12-18 14:16:15 UTC 
I'd like to add, that an alternative fix would be that NetworkManager would just honor the NM_CONTROLLED setting regardless of HWADDR (as there are some devices like bonds that have potentially changing mac addresses) and that they would use the ip device name just like you can get it in org.freedesktop.NetworkManager.GetDeviceByIpIface
Comment 2 Lukáš Nykrýn 2012-12-18 14:18:25 UTC 
From sysconfig.txt:
"NM_CONTROLLED=yes|no 
If set to 'no', NetworkManager will ignore this connection/device."
So I think that this behavior should be fixed in NM and only if it can't be fixed there we should talk about workaround it in initscripts.
Comment 4 Pavel Šimerda (pavlix) 2012-12-18 15:16:04 UTC 
(In reply to comment #1)
> I'd like to add, that an alternative fix would be that NetworkManager would
> just honor the NM_CONTROLLED setting regardless of HWADDR (as there are some
> devices like bonds that have potentially changing mac addresses) and that
> they would use the ip device name just like you can get it in
> org.freedesktop.NetworkManager.GetDeviceByIpIface

This will not change any soon.
Comment 5 Pavel Šimerda (pavlix) 2012-12-18 15:26:44 UTC 
(In reply to comment #2)
> From sysconfig.txt:
> "NM_CONTROLLED=yes|no 
> If set to 'no', NetworkManager will ignore this connection/device."
> So I think that this behavior should be fixed in NM and only if it can't be
> fixed there we should talk about workaround it in initscripts.

AFAIK NetworkManager doesn't handle files without HWADDR at all, I don't think this is a viable solution. Let's wait for Dan's comment on this.

But what Antoni is asking for, is actually not a workaround for a NM bug. He just wants the network scripts to ignore *all* interfaces that NetworkManager manages.

That could happen at any time. You can have conflicting configuration in /etc/sysconfig/network-scripts and /etc/NetworkManager/system-connections, for example.

But there's no NM tool network scripts could ask when NM is not started (yet).
Comment 6 Bill Nottingham 2012-12-18 18:38:35 UTC 
Having it changed to ignore all interfaces that NM manages would be a change of behavior that isn't really appropriate for a minor RHEL update, in my opinion.
Comment 7 Antoni Segura Puimedon 2012-12-18 20:42:31 UTC 
(In reply to comment #6)
> Having it changed to ignore all interfaces that NM manages would be a change
> of behavior that isn't really appropriate for a minor RHEL update, in my
> opinion.

Well, if it can't be for 6.4, at least I think they should play nice for Fedora 17+ and the future major version of RHEL.
Comment 8 RHEL Program Management 2012-12-24 06:53:19 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 11 Dan Williams 2013-02-25 23:32:23 UTC 
(In reply to comment #7)
> (In reply to comment #6)
> > Having it changed to ignore all interfaces that NM manages would be a change
> > of behavior that isn't really appropriate for a minor RHEL update, in my
> > opinion.
> 
> Well, if it can't be for 6.4, at least I think they should play nice for
> Fedora 17+ and the future major version of RHEL.

Yes, this is likely to be fixed in F19+ and future versions of RHEL.  See bug 824130, which I'm duping this bug to since the fix for both is the same.

*** This bug has been marked as a duplicate of bug 824130 ***
Note You need to log in before you can comment on or make changes to this bug.