Bug#990283: openvpn: Upgrades break systemd supervision

[hosts+proute...@sflc.info]

Package: openvpn
Version: 2.4.7-1+deb10u1
Severity: normal

Shortly after the release of 2.4.7-1+deb10u1, a system with unattended-upgrades configured started to complain:

> Jun 21 06:07:19 prouter10 systemd[1]: apt-daily-upgrade.service: Found left-over process 9788 (openvpn) in control group while starting unit. Ignoring.
> Jun 21 06:07:19 prouter10 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
> Jun 21 06:07:19 prouter10 systemd[1]: apt-daily-upgrade.service: Found left-over process 9809 (openvpn) in control group while starting unit. Ignoring.
> Jun 21 06:07:19 prouter10 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
> Jun 21 06:07:19 prouter10 systemd[1]: Starting Daily apt upgrade and clean activities...

`systemctl status` reveals that my `openvpn@.service` units are dead, and my openvpn processes are now sitting inside my `apt-daily-upgrade.service` cgroup. Pretty sure that's not what we want.

-- System Information:
Debian Release: 10.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvpn depends on:
ii debconf [debconf-2.0] 1.5.71
ii iproute2 4.20.0-2+deb10u1
ii libc6 2.28-10
ii liblz4-1 1.8.3-1+deb10u1
ii liblzo2-2 2.10-0.1
ii libpam0g 1.3.1-5
ii libpkcs11-helper1 1.25.1-1
ii libssl1.1 1.1.1d-0+deb10u6
ii libsystemd0 241-7~deb10u7
ii lsb-base 10.2019051400

Versions of packages openvpn recommends:
ii easy-rsa 3.0.6-1

Versions of packages openvpn suggests:
ii openssl 1.1.1d-0+deb10u6
pn openvpn-systemd-resolved <none>
pn resolvconf <none>

-- debconf information:
openvpn/create_tun: false

[Daniel Gnoutcheff]

Hello Jörg, thanks for the reply.

> Was the computer rebooted after the update?

It was not. Rebooting fixes the issue, as does manually kill(1)ing the
errant openvpn instances and restarting the systemd unit(s).

Sorry, "Upgrades break systemd supervision" was perhaps not the best
summary. It's more like "Upgrades restart openvpn outside of
systemd".

> I have checked your bug report on every server I have access to.
>
> Likewise, I have checked the problem in multiple VMs. The error was not
> reproducible there either.

This worked for me on a fresh amd64 buster VM:

echo "deb http://snapshot.debian.org/archive/debian/20210601T022916Z/ buster main" >/etc/apt/sources.list.d/snapshot.list
apt update
apt install openvpn=2.4.7-1 ssl-cert

# placeholder config
zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz >/etc/openvpn/server.conf
ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/openvpn/server.crt
ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/openvpn/ca.crt
ln -s /etc/ssl/private/ssl-cert-snakeoil.key /etc/openvpn/server.key
openssl dhparam -out /etc/openvpn/dh2048.pem 2048
openvpn --genkey --secret /etc/openvpn/ta.key

systemctl start openvpn@server

apt install unattended-upgrades
systemctl start apt-daily-upgrade
systemctl status
# Observe: openvpn process is now in apt-daily-upgrade.service
systemctl start apt-daily-upgrade # (a second time)
# systemd now warns about the lingering process

Alternatively, replace 'apt install unattended-upgrades' and everything
thereafter with:

apt upgrade
systemctl status

Which should show the openvpn daemon lingering in whatever scope unit
contains your shell.

Or, simpler still:

invoke-rc.d openvpn cond-restart

which is invoked by openvpn's postinst and has much the same effect.

> Can you please provide the complete update logs?

Attached are extracts of of `journalctl --output=with-unit` and
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log after having
done the above. HTH!

Thanks,
--
Daniel Gnoutcheff
Systems Administrator
Software Freedom Law Center