I tested this on my managed VPN service running on CentOS 7 (update from 2.3.x to 2.4.1), it works like a charm I must say! Great the old (systemd) service file is still there. Will report back here if there are any issues...

@fkooman, there is a potential issue with this update where OpenVPN will not start after a reboot if using the old and deprecated openvpn@.service units. The new ones (openvpn-client@.service and openvpn-server@.service) should work fine.

I will backport several of the packaging enhancements from rawhide and F25 which should resolve this issue - and a few other ones as well. Hopefully I will manage that this week.

@dsommers, it seems /var/run/openvpn does not exist anymore after reboot, only /var/run/openvpn-{client,server}. That's the issue you are talking about? I'm looking to move to the server one soon though!

Yes! I have received some positive reports on these exact changes in F25 and F26, so I will update this update with a new build during today. Bugzilla #1435831is the one covering this issue.

This update has been unpushed.

@fkooman, Those issues we've discussed should be covered by this new openvpn-2.4.1-2.el7 build. This build should not break openvpn@.service units upon boot any more.

@dsommers, I updated to -2 and everything seems fine, not sure how you fixed things, but my fix consisted of adding an extra entry to the tmpfiles file, that worked too :)

The second part of my answer in comment #9 in #1435831 actually answers that. The TL;DR answer is that OpenVPN v2.4 can talk directly to systemd and does not need to use PID files and a directory where to save them. This is solved by using Type=notify, which OpenVPN detects and uses sd_notify() under the hood.

In addition, if not using that approach but using Type=simple instead of Type=fork which the previous unit file used, the need to use both --daemon and PID files also goes away. So the approach used in the old unit file actually never was a good solution at all, making it unnecessary complicated by needing a tmpfiles.d config in addition.

However, using Type=notify have the advantage of ignoring --daemon in OpenVPN configuration files automatically. Which is not needed. The old approach or using the simpler Type=simple approach could havoc if the config file itself contains --daemon.

The old approach or using the simpler Type=simple approach could havoc if the config file itself contains --daemon.

Just noticed this is slightly too much simplified and wrong.

The old approach had to use --daemon, as Type=fork tells systemd "this process forks a child process". Otherwise it would fail. And then it was required to use a PID file so systemd actually could manage the process somewhat.

Using just Type=simple (which is the default, if Type= is not provided) will fail if the OpenVPN configuration uses --daemon, as then the OpenVPN processes forks of a child process, daemonizes it and the parent process quits. Systemd would then be confused by this, as it doesn't expect the (parent) process to quit just like that.

So with Type=notify, OpenVPN actually detects that it is systemd who started the process, and then provides a "status string", including its PID value via sd_notify() inside the OpenVPN process directly. And when this is done, OpenVPN just ignores forking daemonizing if --daemon is provided, as that is not needed with this approach. So if a configuration file carries --daemon, it doesn't break anything by confusing systemd by the forking and daemonizing steps.

Works perfectly fine. No regressions noted.

Working fine for me.

@dsommers thanks for the extensive explanation! :)

Working fine for me as well.