+++ This bug was initially created as a clone of Bug #1344411 +++ Scenario: - NetworkManager is running, with monitor-connection-files=no (which is the default). Currently NetworkManager is managing the interface "eth0", for example because there is no ifcfg file with NM_CONTROLLED=no. - user creates a new ifcfg-eth0, with NM_CONTROLLED=no - user calls `ifup eth0` Result: NetworkManager does not learn that it should not manage the configuration. Instead, ifup will activate eth0 without using nmcli, and NetworkManager continues to interfere. That is due to: if ! is_false $NM_CONTROLLED && is_nm_running; then nmcli con load "/etc/sysconfig/network-scripts/$CONFIG" UUID=$(get_uuid_by_config $CONFIG) [ -n "$UUID" ] && _use_nm=true fi Expected Behavior: ifup should notify NetworkManager to reload the file. Like: if is_nm_running; then nmcli con load "/etc/sysconfig/network-scripts/$CONFIG" if ! is_false $NM_CONTROLLED; then UUID=$(get_uuid_by_config $CONFIG) [ -n "$UUID" ] && _use_nm=true fi fi
Change looks sane to me -> devel_ack.
Maybe we should also replace nmcli con load "/etc/sysconfig/network-scripts/$CONFIG" with dbus-send --system --print-reply \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager/Settings \ org.freedesktop.NetworkManager.Settings.LoadConnections \ array:string:"/etc/sysconfig/network-scripts/$CONFIG" On a quick test (on my particular machine), the dbus-send call takes about 4ms, while the nmcli call takes 215ms.
> On a quick test (on my particular machine), the dbus-send call takes about > 4ms, while the nmcli call takes 215ms. I think you should fix this in NM :-).
+1
https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel7-branch&id=a4eefc6bdfb1e6872ef83428b833a0cc6474e8e2 -> post
Would you be kind to release this fix in a quick z-stream, as it affects RHEV-4.0 badly
Thanks Marcel for the PMApproval for z-stream inclusion. Do we know yet which z-stream it will be included in?
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. https://rhn.redhat.com/errata/RHBA-2016-2456.html