[Focal-only] openvpn postinst script restarts with init.d, resulting in duplicate openvpn processes

[Thayne]

On Ubuntu 20.04.2 with openvpn 2.4.7-1ubuntu2.20.04.2:

The postinst script for openvpn has the following:

if [ -x "/etc/init.d/openvpn" ]; then
 pathfind invoke-rc.d
 if [ $? = 0 ]; then
    invoke-rc.d openvpn cond-restart || invoke-rc.d openvpn restart
 else
    /etc/init.d/openvpn cond-restart || /etc/init.d/openvpn restart
 fi
fi

and since cond-restart isn't one of start,stop,restart, or try-restart, invoke-rc.d will kill the openvpn processes managed by systemd and start a new process using the init.d script. If the systemd service is later restarted, this results in two processes for the same openvpn configuration that conflict with each other.

Some ways this could be fixed:

1. Don't run the cond-restart in the postinst script
2. Change inti.d to defer to systemd to start the daemon, at least for cond-restart
3. Stop using the init.d script altogether.
3. Change the systemd service to make sure to kill conflicting processes as part of a restart.

[Utkarsh Gupta (utkarsh)]

Hello Thayne,

Thank you for taking out time to file this bug and help make Ubuntu server better. Your bug report and suggestions make sense. And furthermore, Debian has dropped it as well in the subsequent releases:
https://salsa.debian.org/debian/openvpn/-/commit/5cc614d90d3150e26e87ac55c44cf6e358011156

So this is for sure actionable. Since this has already been fixed in Groovy, Hirsute, and Impish, somebody will need to prepare an SRU[1] for this to Focal. Also, since this isn't something that requires immediate attention, I am marking this as of "low" severity so that it could be piggy-backed with other fixes.

In case you're interested in preparing the update by following the process, let us know :)

Thanks!

[1]: https://wiki.ubuntu.com/StableReleaseUpdates

[Bryce Harrington (bryce)]

Hi Thayne,

I've posted a PPA that packages this fix for focal:

https://launchpad.net/~bryce/+archive/ubuntu/openvpn-fix-lp1928367

I think we can potentially submit this as a Stable Release Update (SRU), however first we need to define a paint-by-numbers set of steps to reproduce this issue (and confirm the fix). It would be very helpful if you could assist in jotting down the steps. I'd appreciate as well if you can test my PPA to doublecheck that it does indeed solve the problem.

[Bryce Harrington (bryce)]

Looking through the sru history for openvpn I see that restart mis-behaviors are common topics for SRUs. So, while I sincerely doubt anyone is dependent on use of cond-restart, any changes to restart behavior in general are going to incur risk. IOW I think we should be very confident this change is important before proceeding with an SRU.

In looking through our existing bug reports I've not spotted any obvious dupes of this, nor is google turning up examples of this problem more generally. Nor have I reproduced the issue myself, although that may just be down to configuration ignorance on my part.

What we would need in order to move forward with an SRU for this change would be a paint-by-number test case, that includes client and server config files, a script or set of commands, and expected/actual output or log messages that identify the problem. You can see examples of what we need by looking at some of the '[Test Plan]' sections in past accepted SRUs for openvpn such as LP: #1934781 and LP: #1787208.

Along with that, for this bug in particular we need to have a convincing [Impact] section, since this is removing functionality for an issue that seems not very widely experienced. Any justifications and rationale you can suggest would be helpful.

[Thayne (thayne-u)]

I'm sorry I haven't been more responsive on this ticket.

To fix my issue I have implemented a workaround where I add

    ExecStartPre=-+start-stop-daemon --stop --oknodo --pidfile /run/openvpn/%i.pid --exec /usr/sbin/openvpn

To an override file in /etc/systemd/system/openvpn@.service.d. So that when the systemd service for openvpn starts, it first kills any existing openvpn process to make sure there aren't conflicts.

Since I have a workaround, it hasn't been a high priority, and I've been really busy.

I don't have a lot of time to try reproducing without my fix, but here is what I remember of the situation that caused it.

the openvpn configuration looked something like:

```
port 443
proto tcp4
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.key
topology subnet
server 10.0.0.0 255.255.255.0
push "topology subnet"
push "route-gateway 10.0.0.1"

push "route 10.0.0.0 255.255.255.0"

push "dhcp-option DNS 10.0.0.2"
push "dhcp-option DNS 10.0.0.3"

client-connect /etc/openvpn/client_connect_script
auth-user-pass-verify /etc/openvpn/pass_verify_script.sh via-env

max-clients 2048
script-security 3
keepalive 10 120
compress lzo
persist-key
persist-tun
```

And I had something that would periodically start the systemd service if it wasn't already started.

Then sometime after installing an update to openvpn, I would endp up with duplicate openvpn processes.

[Bryce Harrington (bryce)]

Hi Thayne,

I've circled around to this and am checking in again. I am glad you have a viable workaround, and it looks like others haven't run into this same problem, so at least the impact of this issue is not very severe. Thanks for the config snippet, that could be handy if anyone tries to sort out the reproduction steps. (I took another stab just at reproducing in a focal lxc but suspect I'm still missing some steps.) We'll probably want to hold off on SRU for this until that's defined, or until someone gives confirmation on the PPA fix.

Thanks again, and good luck!