Bug 1513613
| Summary: | Cannot disable NetworkManager.service on F27 | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew <maulx86> | |
| Component: | NetworkManager | Assignee: | Lubomir Rintel <lkundrak> | |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 27 | CC: | alexl, bgalvani, dcbw, fgiudici, germano.massullo, gnome-sig, john.j5live, lkundrak, mclasen, rhughes, rstrode, sandmann, sherr, thaller, zbyszek | |
| Target Milestone: | --- | |||
| 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: | ||||
| : | 1520865 (view as bug list) | Environment: | ||
| Last Closed: | 2018-01-11 15:58:17 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
Andrew
2017-11-15 16:56:36 UTC
After some more testing here, I found the root cause of the issue. To prevent NetworkManager.service from starting in F27, you also need to disable NetworkManager-wait-online.service. systemctl disable NetworkManager.service systemctl disable NetworkManager-wait-online.service The "/usr/lib/systemd/system/NetworkManager-wait-online.service" was changed. In F26, we have: Requisite=NetworkManager.service. Whereas in F27, we have: Requires=NetworkManager.service. This affected me as well. I also use static network configs. During the F26->F27 upgrade NetworkManager re-enabled itself and the result was a broken network after the upgrade. NetworkManager should stay disabled if it has been disabled. this looks like working as expected. disabled does not mean that a service cannot start. If another service requires NM.service, it will still be started. If you don't want it to ever start, you need to mask it. In this case, NM-wait-online.service changed to require NM: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=28b97f02f64ecf94e22c8929dfd0ba64151bd9d3 I think while the change is painful (and causing issues -- sorry about that), it is still right. The change fixes another issue. But in this case the "other service" is something that NetworkManager itself creates. It's not like Some Other Thing needed NetworkManager to be running in order to function. If that were the case then yes, it would be reasonable for systemd to start NetworkManager. This problem is entirely self-contained in NetworkManager, so no it's not reasonable that it should start ignoring its configuration and auto-start anyway. what this change fixes is that `systemctl start network-online.target` will start NM (and wait until it's connected) -- provided you have NM-wait-online enabled. Arguably, NM-wait-online is enabled by default, so this effectively means that if you want to disable NM, in most cases you also have to disable NM-wait-online. -- or mask NM. You are correctly describing the situation that lead to this bug, but that's not the point. The point is that NM-wait-online is a part of NM. NM provides it and can make it behave however it wants to. It's not "another service", it is a part of NM. With this change "systemctl disable NetworkManager" is a essentially a no-op (unless you magically happen know that you also have to disable NM-wait-online for some reason). And it should not be a no-op, it should disable NetworkManager. Not disabling the service that you just told it to disable should be considered a bug in its own right. The point is also that you shouldn't *change* behavior like this. If this was always how NM had behaved with the systemd transition then that would be one thing and people would be used to it. But you can't have it switch from being actually disabled one second to not actually disabled another. Is there really no way to tell systemd about dependencies on a disable action? IE, "if someone disables NM then also disable NM-wait-online"? Because if there is then you should be doing it, and when deploying this change you should have detected if NM was disabled and disabled NM-wait-online too. The change was done for a purpose: to fix bug 1452866. The corresponding change to systemd-networkd-wait-online.service summarizes it well: https://github.com/systemd/systemd/commit/9db307820e6f545665fc87f255af737228b7183c You didn't address a single thing I said in comment 6. I understand that you're not happy with NM.service being pulled in by NM-w-o.service. The change in F27 is not backward compatible :( Nevertheless, previous state was very confusing for users, and we (as in upstream systemd developers with cooperation of NM maintainers) decided to do the conversion, even though it's breaks some setups. The old system did not work properly, see the bugs and commits linked above for a longer discussion. > The point is that NM-wait-online is a part of NM. NM provides it and can make it behave however it wants to. It's not "another service", it is a part of NM. That's not really true. Both NM-wait-online.service and NM.service are systemd units and their behaviour is governed by systemd. This is particularly true for their enabling and disabling — those units might not even be running, the code that does enable/disable is entirely in systemd. > Is there really no way to tell systemd about dependencies on a disable action? IE, "if someone disables NM then also disable NM-wait-online"? Not really. We have "Also=" setting, but it works both ways, i.e. both during enablement and disablement. So your problem would be solved but people would enable NM-w-o.service unexpectedly when enabling NM.service. tl;dr version: use 'systemctl disable NetworkManager\*' to disable all NM units. Ok, so it sounds like we don't want to change this back for Fedora. Closing. *** Bug 1533528 has been marked as a duplicate of this bug. *** |