Netplan and NetworkManager interaction bug

snap
1

Hi!

I am trying to use a NetworkManager with the netplan tool in the Ubuntu Core and can’t get it working.

The actual error I am getting is:

pi@localhost:~$ sudo netplan apply
Failed to stop NetworkManager.service: Unit NetworkManager.service not loaded.
Traceback (most recent call last):
  File "/usr/sbin/netplan", line 387, in <module>
    eval('command_' + args.command.replace('-', '_'))()
  File "/usr/sbin/netplan", line 287, in command_apply
    subprocess.check_call(['systemctl', 'stop', '--no-block', 'NetworkManager.service'])
  File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['systemctl', 'stop', '--no-block', 'NetworkManager.service']' returned non-zero exit status 5

It seems that the issue is related to the netplan tool because it doesn’t know that in Core NetworkManager service has a different name.

Here is the whole bash session for reference: https://paste.ubuntu.com/26523117/

2

I see your point about the netplan python seemingly hardcoding [1] the debian pkg’s netman service name so apparently not stopping the service on Core. I look forward to hearing from other folks to see if they agree.

If so, I suppose netplan could check if Core or not and stop the right service name.

Or, I wonder if snapcraft could (or already DOES?) support systemd service alias. If so, perhaps the neetwork-manager snap’s snapcraft.yaml could define the app/daemon with the same name (via alias [1]) as is used in debian env.

[1] line 287 in /usr/sbin/netplan: subprocess.check_call([‘systemctl’, ‘stop’, ‘–no-block’, ‘NetworkManager.service’])

[2] https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

Which includes this:
“Alias=: This directive allows the unit to be enabled under another name as well. Among other uses, this allows multiple providers of a function to be available, so that related units can look for any provider of the common aliased name.”

4

@kyleN Unfortunately there doesn’t appear to be any support for specifying a systemd service alias in snapcraft (see schema). Snapcraft already has a field called aliases, so this might be confusing, although it’s a good idea and is probably deserves its own post.

I think the best approach for resolving this bug would be to file a bug against netplan, and then create a patch and associate with the bug. That said, getting this into 16.04 would require an SRU (which shouldn’t be too difficult as netplan lives in universe).

1 Like
5

Well, Netplan is not in the wrong here, since NetworkManager.service is the upstream service name. It’s contorted in Debian/Ubuntu to network-manager.service. If Netplan is getting patched, it should only be downstream in Ubuntu.

6

@Conan_Kudo This isn’t an issue between network-manager.service (which looks to be from pre 0.9.8-4 Debian package) and the newer NeworkManager.service file, it’s that netplan is being run on an Ubuntu Core 16 image where NetworkManager is being provided by a snap, which also results in a non-matching service name, snap.network-manager.networkmanager.service.

As @kyleN pointed out, if snapd/snapcraft grew support for systemd’s service unit Alias field, this could be easily solved. We’ll raise this with the snapd team, as this may impact the ability of other well-known services to be deployed as snaps.

Re: only patching this in the downstream Ubuntu package(s), yes that makes sense.

7

We have an actual regression here. pitti uploaded a patch once ago to xenial (see https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1627641/comments/16) which was fixing this but was not adopted upstream as for 18.04 we were supposed to have a better way to fix this. However with the latest upload to xenial (backport of netplan) this patch was dropped (see http://changelogs.ubuntu.com/changelogs/pool/universe/n/nplan/nplan_0.32~16.04.3/changelog).

8

filed this: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1747714