Bug 1513613 - Cannot disable NetworkManager.service on F27
Summary: Cannot disable NetworkManager.service on F27
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 27
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1533528 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-15 16:56 UTC by Andrew
Modified: 2018-03-24 20:12 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1520865 (view as bug list)
Environment:
Last Closed: 2018-01-11 15:58:17 UTC


Attachments (Terms of Use)

Description Andrew 2017-11-15 16:56:36 UTC
Description of problem:

The current release of F27 does not allow NetworkManager to be disabled. Because of this behavior, NetworkManager conflicts with the legacy network scripts ( /etc/sysconfig/network-scripts/ifcfg-* ).

I first noticed this issue in yesterday's F27 final release, it was not present in the F27 beta.

The command used is: systemctl disable NetworkManager.service

Version-Release number of selected component (if applicable):

F27 (installed via ISO).

How reproducible:

Every tested install using the F27 ISO.

Steps to Reproduce:
1. Start with a fresh install of F27.
2. Disable NetworkManager ( systemctl disable NetworkManager.service )
3. Create a standard IPv4/DHCP ifcfg style script ( /etc/sysconfig/network-scripts/ifcfg-ens3 )

  DEVICE="ens3"
  BOOTPROTO="dhcp"
  ONBOOT="yes"
  TYPE="Ethernet"
  NM_CONTROLLED="no"
  IPV6_AUTOCONF="yes"
  IPV6INIT="yes"
  NOZEROCONF="yes"
  ZONE=FedoraServer

4. Enable the legacy "network" service ( chkconfig network on )

Actual results:

NetworkManager.service starts on boot, regardless of disabling the systemd unit.

Expected results:

NetworkManager.service does not start on boot, but the legacy service (network.service) starts and manages the network.

Additional info:

Here are the results of running "systemctl disable NetworkManager.service" then rebooting on both an F27 beta install, and the final F27 release install.


--------------------

F27 BETA

[root@f27-beta ~]# dnf list installed | grep -i "NetworkManager"
NetworkManager.x86_64               1:1.8.4-4.fc27              @updates-testing
NetworkManager-bluetooth.x86_64     1:1.8.4-4.fc27              @updates-testing
NetworkManager-libnm.x86_64         1:1.8.4-4.fc27              @updates-testing
NetworkManager-team.x86_64          1:1.8.4-4.fc27              @updates-testing
NetworkManager-wifi.x86_64          1:1.8.4-4.fc27              @updates-testing
NetworkManager-wwan.x86_64          1:1.8.4-4.fc27              @updates-testing
cockpit-networkmanager.noarch       151-2.fc27                  @updates-testing

[root@f27-beta ~]# systemctl | grep -i "network" | grep -i "\.service"
  fedora-import-state.service                                                         loaded    active exited    Import network configuration from initramfs
  network.service                                                                     loaded    active running   LSB: Bring up/down networking

--------------------

F27 RELEASE

[root@f27-release ~]# dnf list installed | grep -i "NetworkManager"
NetworkManager.x86_64               1:1.8.4-6.fc27              @updates
NetworkManager-bluetooth.x86_64     1:1.8.4-6.fc27              @updates
NetworkManager-libnm.x86_64         1:1.8.4-6.fc27              @updates
NetworkManager-team.x86_64          1:1.8.4-6.fc27              @updates
NetworkManager-wifi.x86_64          1:1.8.4-6.fc27              @updates
NetworkManager-wwan.x86_64          1:1.8.4-6.fc27              @updates
cockpit-networkmanager.noarch       154-1.fc27                  @updates

[root@f27-release ~]# systemctl | grep -i "network" | grep -i "\.service"
  fedora-import-state.service                                                         loaded active exited    Import network configuration from initramfs
  network.service                                                                     loaded active running   LSB: Bring up/down networking
● NetworkManager-wait-online.service                                                  loaded failed failed    Network Manager Wait Online
  NetworkManager.service                                                              loaded active running   Network Manager

--------------------

Comment 1 Andrew 2017-11-15 17:53:05 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.

Comment 2 Stephen Herr 2017-11-28 15:39:43 UTC
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.

Comment 3 Thomas Haller 2017-11-28 17:55:03 UTC
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.

Comment 4 Stephen Herr 2017-11-28 18:07:58 UTC
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.

Comment 5 Thomas Haller 2017-12-04 14:21:05 UTC
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.

Comment 6 Stephen Herr 2017-12-04 16:12:07 UTC
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.

Comment 7 Thomas Haller 2017-12-04 18:49:52 UTC
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

Comment 8 Stephen Herr 2017-12-04 20:10:51 UTC
You didn't address a single thing I said in comment 6.

Comment 9 Zbigniew Jędrzejewski-Szmek 2017-12-04 20:59:17 UTC
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.

Comment 10 Thomas Haller 2018-01-11 15:58:17 UTC
Ok, so it sounds like we don't want to change this back for Fedora. Closing.

Comment 11 Germano Massullo 2018-03-24 20:12:55 UTC
*** Bug 1533528 has been marked as a duplicate of this bug. ***


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