Bug 1400783 - service network restart and systemctl restart network doesn't accept domain and dns changes in ifcfg files for bonds.
Summary: service network restart and systemctl restart network doesn't accept domain a...
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: Unspecified Unspecified
medium
urgent
Target Milestone: rc
: ---
Assignee: sushil kulkarni
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-02 04:56 UTC by jnikolak
Modified: 2016-12-07 06:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-06 18:10:21 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description jnikolak 2016-12-02 04:56:44 UTC
Reproducer
##################

service network restart and systemctl restart network doesn't accept domain and dns changes in ifcfg files for bonds.

But works without bond.

nmcli connection add type bond con-name bond0 mode active-backup ifname bond0
Connection 'bond0' (bd935f3f-c391-4072-8974-d461996e818b) successfully added.
[root@rhel7a network-scripts]# ls -la
total 248
drwxr-xr-x. 2 root root  4096 Dec  2 14:14 .
drwxr-xr-x. 7 root root  4096 Dec  1 11:46 ..
-rw-r--r--. 1 root root   357 Dec  2 14:14 ifcfg-bond0

copy the static details from ifcfg-ens3
IPADDR=10.0.0.3
PREFIX=23
DOMAIN=test.com
GATEWAY=10.0.0.254
DNS1=10.0.0.2


nmcli connection delete ens3
### network down here, ensure you have console


## adding the slave to bond0, repeat process for more slave
nmcli con add type bond-slave ifname ens3 master bond0 con-name ens3
Connection 'ens3' (0e9981be-c1c2-483a-8b5a-4f5025f6648d) successfully added.

vim ifcfg-bond0 
added the config

# reload the configuration
nmcli connection reload


# reload the network
systemctl restart NetworkManager

or service network restart

cat /etc/resolv
"empty"



#### Workaround found
### Make changes to your bond
vi ifcfg-bond0

### reload all config files
nmcli connection reload

[root@rhel7a network-scripts]# nmcli dev connect bond0
Device 'bond0' successfully activated with 'bd935f3f-c391-4072-8974-d461996e818b'.

[root@rhel7a network-scripts]# cat /etc/resolv.conf 
# Generated by NetworkManager
search test.tester.com test2
nameserver 8.8.8.8

Comment 1 Thomas Haller 2016-12-02 09:56:23 UTC
When you update a connection that is currently active, eg via
    nmcli connection load "$IFCFG_NAME"
    nmcli connection reload
or
    nmcli connection modify "$CON"
These commands only modify the connection profile. The changes do not take effect immediately on already activated devices. That is intentional.
Note the distinction between
  - connection (profile)
  - actual device (networking interface)




If you want to apply the changed connection, you need do one of:

  # reactivate connection, implicitly doing a down+up
  nmcli connection up "$CON"   

  # reconnect the device, doing a down+up.
  nmcli device connect $DEV

  # legacy initscripts invoke `nmcli connection up`
  ifup $NAME

  # a more graceful way is reapply, which doesn't do a full down+up cycle and 
  # you don't loose connectivey:
  nmcli device reapply $DEV




On the other hand, if you add a connection (or modify a connection that is currently not active), the connection might start autoconnecting right away, depending on it's connection.autoconnect setting. That leads to a confusing situation that:

  nmcli connection add type ethernet con-name T iface '*'
  # at this point, the new connection might already activate on the device
  # with incomplete configuration.
  nmcli connection modify T ipv4.dns 8.8.8.8

The solutions for that are:
  # do all in one step:
  nmcli connection add type ethernet con-name T iface '*' ipv4.dns 8.8.8.8

  # after the last modification, re-activate the connection, see before.
  nmcli connection modify T ipv4.dns 8.8.8.8
  nmcli connection up T

  # don't use autoconnect initially.
  nmcli connection add type ethernet con-name T iface '*' autoconnect no
  nmcli connection modify T ipv4.dns 8.8.8.8 connection.autoconnect yes





> # reload the network
> systemctl restart NetworkManager

> or service network restart

these are two very different things. One restart NetworkManager.service, the other restarts legacy network.service.

Why are you restarting NetworkManager? See above how to apply changes to a connection. Restarting NetworkManager is almost always the wrong thing to do. Certainly it is wrong to restart NM in order to activate a connection. In fact, it does not. On restart, NM will not change the networking configuration
-- contrary to restarting network.target, which calls ifup for each interface.




The mentioned "workaround" is the right way to do it.

Comment 3 jnikolak 2016-12-06 18:09:21 UTC
Hello, thanks for clearing that up:

service network restart will restart the network.service (legacy network)
systemctl restart NetworkManager will just restart the NM service.

Have no play at all with reflecting changes to ifcfg* files, unless the configuration files are in legacy format. 

Both commands should not be used, instead the 4 commands you have mentioned.
I think I'll create a good kcs to reflect that info.


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