NetworkManager renderer sometimes requires networkd

[Ross Vandegrift]

On an Armbian trixie box, with netplan.io 0.107-5, I've found that `renderer: NetworkManager` can still require systemd-networkd. That's a problem for me since networkd causes the NICs on this box to disappear [1].

Here's my basic working config:
  $ sudo netplan get
  network:
    version: 2
    renderer: NetworkManager
    ethernets:
      enP4p65s0:
        dhcp4: true

If I add things like `mtu: 9000` that affect the device config, netplan writes a .link unit to /run/systemd/network/10-netplan-enP4p65s0.link.

As a result of that file existing, `netplan apply` makes some bad decisions:
- it wants to restart systemd-networkd (that fails because the unit is masked)
- it stops NetworkManager.service (which kills the network)

IMO netplan shouldn't generate any .link files if it isn't using the networkd renderer - there might be some reason that network is not desirable. In this case, if NM cannot e.g. set the mtu, netplan should reject the configuration.

If that's not possible, the docs should be updated to explain when networks is required, even when other renderers are in use.

Full output of apply:
  $ sudo netplan --debug apply
  ** (generate:3604): DEBUG: 20:19:03.977: starting new processing pass
  ** (generate:3604): DEBUG: 20:19:03.978: We have some netdefs, pass them through a final round of validation
  ** (generate:3604): DEBUG: 20:19:03.978: enP4p65s0: setting default backend to 2
  ** (generate:3604): DEBUG: 20:19:03.978: Configuration is valid
  ** (generate:3604): DEBUG: 20:19:03.979: Generating output files..
  ** (generate:3604): DEBUG: 20:19:03.979: networkd: definition enP4p65s0 is not for us (backend 2)
  ** (generate:3604): DEBUG: 20:19:03.979: Open vSwitch: definition enP4p65s0 is not for us (backend 2)
  DEBUG:netplan generated networkd configuration changed, reloading networkd
  WARNING:Cannot call Open vSwitch: ovsdb-server.service is not running.
  DEBUG:netplan generated NM configuration changed, restarting NM
  ** (process:3603): DEBUG: 20:19:04.605: starting new processing pass
  ** (process:3603): DEBUG: 20:19:04.605: We have some netdefs, pass them through a final round of validation
  ** (process:3603): DEBUG: 20:19:04.605: enP4p65s0: setting default backend to 2
  ** (process:3603): DEBUG: 20:19:04.605: Configuration is valid
  DEBUG:Merged config:
  b''
  DEBUG:Link changes: {}
  DEBUG:netplan triggering .link rules for lo
  DEBUG:netplan triggering .link rules for lan1
  DEBUG:netplan triggering .link rules for lan2
  ** (process:3603): DEBUG: 20:19:04.813: starting new processing pass
  ** (process:3603): DEBUG: 20:19:04.813: We have some netdefs, pass them through a final round of validation
  ** (process:3603): DEBUG: 20:19:04.813: enP4p65s0: setting default backend to 2
  ** (process:3603): DEBUG: 20:19:04.813: Configuration is valid
  ** (process:3603): DEBUG: 20:19:04.813: starting new processing pass
  ** (process:3603): DEBUG: 20:19:04.813: We have some netdefs, pass them through a final round of validation
  ** (process:3603): DEBUG: 20:19:04.813: enP4p65s0: setting default backend to 2
  ** (process:3603): DEBUG: 20:19:04.813: Configuration is valid
  DEBUG:Merged config:
  b''
  systemd-networkd is not running, output might be incomplete.
  Failed to reload network settings: Unit dbus-org.freedesktop.network1.service not found.
  WARNING:Falling back to a hard restart of systemd-networkd.service
  Failed to restart systemd-networkd.service: Unit systemd-networkd.service is masked.
  Traceback (most recent call last):
    File "/usr/share/netplan/netplan_cli/cli/commands/apply.py", line 279, in command_apply
      utils.networkctl_reload()
    File "/usr/share/netplan/netplan_cli/cli/utils.py", line 126, in networkctl_reload
      subprocess.check_call(['networkctl', 'reload'])
    File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['networkctl', 'reload']' returned non-zero exit status 1.

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
    File "/usr/sbin/netplan", line 23, in <module>
      netplan.main()
    File "/usr/share/netplan/netplan_cli/cli/core.py", line 58, in main
      self.run_command()
    File "/usr/share/netplan/netplan_cli/cli/utils.py", line 256, in run_command
      self.func()
    File "/usr/share/netplan/netplan_cli/cli/commands/apply.py", line 63, in run
      self.run_command()
    File "/usr/share/netplan/netplan_cli/cli/utils.py", line 256, in run_command
      self.func()
    File "/usr/share/netplan/netplan_cli/cli/commands/apply.py", line 284, in command_apply
      utils.systemctl('restart', ['systemd-networkd.service'], sync=True)
    File "/usr/share/netplan/netplan_cli/cli/utils.py", line 112, in systemctl
      subprocess.check_call(command)
    File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['systemctl', 'restart', 'systemd-networkd.service']' returned non-zero exit status 1.

[1] - Yea really. On subsequent reboots, the PCIe links never come up, so the interfaces can't become active. I'm still trying to track that down.

[Lukas Märdian (slyon)]

The .link files are actually udev configuration, not systemd-networkd (https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html).

But you're right that we should not try to attempt to reload systemd-networkd if no .network configuration was changed (but only .link configuration). Therefore, avoiding the crash.