Bug 1566656
| Summary: | NetworkManager is updating /etc/resolv.conf even if "dns=none" is specified | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Venkatesh Kavtikwar <vkavtikw> |
| Component: | NetworkManager | Assignee: | sushil kulkarni <sukulkar> |
| Status: | CLOSED DUPLICATE | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.5 | CC: | atragler, bgalvani, fgiudici, lrintel, ptalbert, rkhan, sababu, sukulkar, thaller |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-13 11:56:36 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
Venkatesh Kavtikwar
2018-04-12 17:23:37 UTC
Hello Team, Customer for the case 02066088, wants to track the progress of this bugzilla. So can we make this BZ public or can we add customer in CC for the latest updates? This is probably a duplicate of bug 1541031. In comment 0 > How reproducible: > > 1. Mark "dns=none" to /etc/NetworkManager/NetworkManager.conf > 2. Restart NetworkManager [1] > 3. NetworkManager will overwrite content of /etc/resolv.conf Restart means Stop+Start. I would suspect, that NetworkManager writes to resolve.conf during "Stop", and not afterwards. Until "Stop" complets, NetworkManager was not told to reload the configuration from disk (e.g. via kill -HUP, systemctl reload), so, at that point NetworkManager is still in full control of resolv.conf until the process ends, and it's not immediately clear that NetworkManager updated resolv.conf wrongly. At least, the bug talks not about NetworkManager writing something wrong to resolv.conf, instead it expects that editing the configuration file on disk alone, will immediately instruct NetworkManager to stop touching resolv.conf. That's not how it works. You need to either reload the configuration, or expect that the new configuration is honored on the next start (and not earlier). (In reply to Beniamino Galvani from comment #3) > This is probably a duplicate of bug 1541031. I think this is NOTABUG. Hello Thomas, Thanks for your reply. I agree with the above statement that NetworkManager will not read the configuration changes at the time of stopping but at the same time it should not update "/etc/resolv.conf" while going done. It doesn't make any sense of updating "/etc/resolv.conf" while bringing the NetworkManager service down. (In reply to Venkatesh Kavtikwar from comment #5) > Hello Thomas, > > Thanks for your reply. > > I agree with the above statement that NetworkManager will not read the > configuration changes at the time of stopping but at the same time it should > not update "/etc/resolv.conf" while going done. > > It doesn't make any sense of updating "/etc/resolv.conf" while bringing the > NetworkManager service down. I think the subject of the bug is not correct and NOTABUG. Not correct, because if NM is really configured with dns=none, it shouldn't touch resolv.conf (and I don't think that is happening). Note that you could at any time receive a DHCP lease that involves changes which cause to rewrite resolv.conf. That means, - check content of /etc/resolv.conf - systemctl stop NetworkManager - check content of /etc/resolv.conf always has a race, that before NetworkManager stops, something relevant happens that causes NetworkManager to rewrite resolv.conf, and that'd be correct behavior. bug 1541031 is about NetworkManager rewriting resolv.conf with undesired content during shut-down. I think as such, this bug is a duplicate (I agree with Beniamino). Closing. Please comment/reopen, if you disagree. Thank you. *** This bug has been marked as a duplicate of bug 1541031 *** |