Bug 1400783
| Summary: | service network restart and systemctl restart network doesn't accept domain and dns changes in ifcfg files for bonds. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | jnikolak |
| Component: | NetworkManager | Assignee: | sushil kulkarni <sukulkar> |
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | urgent | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | atragler, bgalvani, fgiudici, lrintel, rkhan, sukulkar, thaller |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
jnikolak
2016-12-02 04:56:44 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.
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. |