** Description changed: + [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. + + + [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.
-- 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. [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