[Impact]
* netplan-dbus can time-out and return FALSE after 5 sec (irrespective of the given timeout parameter) on calling the io.netplan.Netplan.Config.Try DBus method
* This happens if a network device is set up, which never finishes configuring in systemd-networkd (e.g. an empty bridge, using DHCP).
[Test Plan]
$ cat ./repro.sh
set -ev
P=$(dbus-send --type=method_call --system --print-reply --dest=io.netplan.Netplan /io/netplan/Netplan io.netplan.Netplan.Config | grep "object path" | cut -d'"' -f2)
echo $P
dbus-send --type=method_call --system --print-reply --dest=io.netplan.Netplan $P io.netplan.Netplan.Config.Set string:bridges.br54.dhcp4=true string:90-foo
dbus-send --type=method_call --system --print-reply --dest=io.netplan.Netplan $P io.netplan.Netplan.Config.Try uint32:300
$ chmod +x repro.sh
$ time ./repro.sh
P=$(dbus-send --type=method_call --system --print-reply --dest=io.netplan.Netplan /io/netplan/Netplan io.netplan.Netplan.Config | grep "object path" | cut -d'"' -f2)
echo $P
/io/netplan/Netplan/config/K0PEL1
dbus-send --type=method_call --system --print-reply --dest=io.netplan.Netplan $P io.netplan.Netplan.Config.Set string:bridges.br54.dhcp4=true string:90-foo
method return time=1651225120.656093 sender=:1.48 -> destination=:1.49 serial=6 reply_serial=2
boolean true
dbus-send --type=method_call --system --print-reply --dest=io.netplan.Netplan $P io.netplan.Netplan.Config.Try uint32:300
method return time=1651225126.820211 sender=:1.48 -> destination=:1.50 serial=8 reply_serial=2
boolean true
real 0m6.352s
user 0m0.019s
sys 0m0.020s
=> Make sure the final io.netplan.Netplan.Config.Try() method call returns TRUE.
[Where problems could occur]
This change touches netplan's dbus daemon (netplan-dbus), so if anything goes wrong problems could occur interacting with the io.netplan.Netplan DBus interface, but should not affect the netplan generator at a system level.
[Other Info]
* The issue has already been fixed for Core20 in netplan.io 0.104-0ubuntu2~20.04.1+core1 via https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image – So no need to rush this as an SRU for Focal
* The fix is already staged for Focal SRU at: https://git.launchpad.net/~ubuntu-core-dev/netplan/+git/ubuntu/commit/?h=ubuntu/focal&id=0fa3404c9627d69adf647db9911cf36cdf9b90b2
=== Original description ===
As part of our snapd core integration testing we run the spread test for netplan on a UC20 PI device.
On this device our test fails with:
"""
2022-03-25 14:33:00 Error executing external:ubuntu-core-20-arm-32:tests/core/netplan-cfg (external:ubuntu-core-20-arm-32) :
-----
+ echo 'Getting version works'
Getting version works
+ snap get system system.network.netplan.network.version
+ MATCH '^2$'
+ echo 'Getting the full document works and it is valid json'
Getting the full document works and it is valid json
+ jq .
+ snap get -d system system.network.netplan
{
"system.network.netplan": {
"network": {
"ethernets": {
"eth0": {
"dhcp4": true,
"match": {
"macaddress": "b8:27:eb:41:42:43"
},
"set-name": "eth0"
}
},
"version": 2
}
}
}
+ echo 'Check that setting adding a br54 interface via netplan works'
Check that setting adding a br54 interface via netplan works
+ snap set system system.network.netplan.network.bridges.br54.dhcp4=true
error: cannot perform the following tasks:
- Run configure hook of "core" snap (run hook "configure": cannot try netplan config: no specific reason returned from netplan)
-----
"""
This error means that snapd called io.netplan.Netplan.Config.Set and got a "false" without an error from that call (c.f. https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/netplan.go#L218)
[edit: now this also fails in GCE testing on amd64 and this looks like a regression as this used to work].
We also observe this behavior now on UC20 systems that run with amd64, e.g. in this run: https:/
The log looks like this:
"""
2022-04-
2022-04-
2022-04-
...
2022-04-
2022-04-
2022-04-
"""