I did apt-get update; apt upgrade on a remote server over SSH. netplan.io and some systemd packages were upgraded. I switched to a different screen window, but after just a few seconds the SSH connection stopped. All network connectivity is now lost.
This happened once before during an update of netplan.io. Then, a simple sudo ifdown (WAN-if); sudo ifup (WAN-if) on the physical console fixed the problem.
My server runs 18.04.1 LTS with blank configuration for netplan, blank configuration for systemd-networkd (which is the backend), with all interfaces statically configured in /etc/network/interfaces, and "ifupdown" installed. Reboots work just fine.
Could it be that netplan apply is only triggered on apt upgrade of netplan.io?
EDIT: These are the packages that were updated that killed the WAN interface, as copied from /var/log/apt/history.log:
Start-Date: 2019-01-15 12:43:10
Commandline: apt upgrade
Requested-By: user (1234)
Upgrade: libkrb5-3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), libgssapi-krb5-2:amd64 (1.16-2build1, 1.16-2ubuntu0.1), netplan.io:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), libcom-err2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), gnupg-utils:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-wks-client:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), python3-software-properties:amd64 (0.96.24.32.6, 0.96.24.32.7), gnupg-l10n:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libibverbs1:amd64 (17.1-1, 17.1-1ubuntu0.1), libsystemd0:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), e2fsprogs:amd64 (1.44.1-1, 1.44.1-1ubuntu1), librbd1:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), ibverbs-providers:amd64 (17.1-1, 17.1-1ubuntu0.1), gpg-wks-server:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libk5crypto3:amd64 (1.16-2build1, 1.16-2ubuntu0.1), udev:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), librdmacm1:amd64 (17.1-1, 17.1-1ubuntu0.1), initramfs-tools-bin:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), libudev1:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), krb5-locales:amd64 (1.16-2build1, 1.16-2ubuntu0.1), nplan:amd64 (0.40.1~18.04.3, 0.40.1~18.04.4), dirmngr:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libss2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), libext2fs2:amd64 (1.44.1-1, 1.44.1-1ubuntu1), psmisc:amd64 (23.1-1, 23.1-1ubuntu0.1), libkrb5support0:amd64 (1.16-2build1, 1.16-2ubuntu0.1), systemd-sysv:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), gpgv:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), libpam-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss-systemd:amd64 (237-3ubuntu10.9, 237-3ubuntu10.11), libnss3:amd64 (2:3.35-2ubuntu2, 2:3.35-2ubuntu2.1), linux-firmware:amd64 (1.173.2, 1.173.3), gnupg:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), gpg-agent:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), librados2:amd64 (12.2.7-0ubuntu0.18.04.1, 12.2.8-0ubuntu0.18.04.1), initramfs-tools-core:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgconf:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), initramfs-tools:amd64 (0.130ubuntu3.5, 0.130ubuntu3.6), gpgsm:amd64 (2.2.4-1ubuntu1.1, 2.2.4-1ubuntu1.2), tzdata:amd64 (2018g-0ubuntu0.18.04, 2018i-0ubuntu0.18.04), software-properties-common:amd64 (0.96.24.32.6, 0.96.24.32.7)
End-Date: 2019-01-15 12:45:04
The WAN interface configuration:
auto eno1
#iface eno1 inet dhcp
iface eno1 inet static
address a.b.c.X
netmask 255.255.255.NNN
gateway a.b.c.Y
dns-nameservers e.f.g.h i.j.k.l
up ip addr add a.b.c.Z/BB dev eno1
The funny thing is that the LAN interface used for trunking, was unaffected (still up and running):
auto eno2
iface eno2 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto vlan3
iface vlan3 inet manual
vlan-raw-device eno2
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
auto br3
iface br3 inet static
address a.b.m.n
netmask 255.255.255.128
up ip addr add a.b.m.n-1/25 dev br3
down ip addr del a.b.m.n-1/25 dev br3
bridge_ports vlan3
bridge_stp off
ifupdown
which caused the network to disconnect. The other issue with this is that it can end the upgrade process once your system disconnected so it may not bring the network backup automatically. Actual server hardware gets around this with remote serial consoles like BMC, iLO or LOM that are not affected by network updates. You will probably need to visit the remote system or have someone close to it check it or reboot it, etc. – Terrance Jan 16 '19 at 16:39