> I think the backport just needs to add a check to not flow through to setting > the > routes until after we've gone through the process of setting the addresses; we > can do that with the attached patch
yeah, maybe, I was thinking more along the lines of needing c42ff3a1a7bfea66dc4655096c79bd481159091b and maybe e4a71bf36f422c3728b902aaa5846add7bbc0eb9, and we might also need 2428613f854f46b6624199c2dc58d02617320133 to actually initialize our flags to false. In short, the backport is much more complex than a quick patch; even if a 1-liner really is all that's needed, I need to look *very* closely at all 4 patches from bug 1812760 to make 100% that's the case. Hence, removing those patches from the current systemd upload, which will fix this bug. Then, I can take more time in the original bug to evaluate the patches. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1818340 Title: systemd-networkd core dumps in bionic-proposed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Released Bug description: [Impact] during restart, systemd-networkd fails an assertion and aborts, leaving the system networking partially (if at all) configured. Further restarts continue to fail. [Test Case] Install a bionic system (cosmic affected also) with only systemd- networkd networking (i.e. uninstall or do not configure netplan). Ensure no networkd conf files are in /run/systemd/network. Stop networkd (sudo systemctl stop systemd-networkd). The interface to test with networkd (e.g. ens3) should have no address assigned and should be down. Create a file similar to below, adjusting for interface name: $ cat /etc/systemd/network/10-netplan-ens3.network [Match] Name=ens3 [Network] Address=192.168.122.68/24 Start networkd: ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd ubuntu@lp1818340-b:~$ ip a show ens3 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe6e:8c9f/64 scope link valid_lft forever preferred_lft forever Stop networkd; ens3 should retain its address: ubuntu@lp1818340-b:~$ sudo systemctl stop systemd-networkd ubuntu@lp1818340-b:~$ ip a show ens3 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe6e:8c9f/64 scope link valid_lft forever preferred_lft forever Start networkd again; the bug is triggered: ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd Job for systemd-networkd.service failed because a fatal signal was delivered causing the control process to dump core. See "systemctl status systemd-networkd.service" and "journalctl -xe" for details. Alternately, instead of separately stopping and then starting networkd, the failure can be reproduced with just a restart. Note the failure only happens with statically-assigned addresses; interfaces configured with dhcp do not trigger this bug. [Regression Potential] TBD [Other Info] This was introduced by the SRU for bug 1812760; both the new behavior of networkd not removing managed addresses/routes from managed interfaces, as well as the assertion failure bug. This does not fail in disco; I believe additional commit(s) from upstream need to be backported. Original description: --- I run a number of servers with -proposed enabled and have seen a bunch of this today: Mar 02 16:20:58 4-ridge-fw1 systemd[1]: systemd-networkd.service: Failed with result 'core-dump'. Mar 02 16:20:58 4-ridge-fw1 systemd[1]: Failed to start Network Service. These machines have numerous bonds, so I suspect that's a factor. So far I have only observed the issue on machines with -proposed enabled so I suspect it is a problem with systemd 237-3ubuntu10.14 Example netplan.yaml attached. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818340/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
