Comment 7 for bug 1868127

I proposed to add the '+' in the supported releases to avoid a failure while users try to reload the service:

$ sudo systemctl reload openvpn@server
Job for <email address hidden> failed because the control process exited with error code.
See "systemctl status <email address hidden>" and "journalctl -xe" for details.
$ echo $?
1
$ sudo systemctl status openvpn@server
● <email address hidden> - OpenVPN connection to server
   Loaded: loaded (/lib/systemd/system/openvpn@.service; indirect; vendor preset: enabled)
   Active: active (running) (Result: exit-code) since Tue 2020-05-26 17:11:33 -03; 24s ago
     Docs: man:openvpn(8)
           https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
           https://community.openvpn.net/openvpn/wiki/HOWTO
  Process: 9548 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=1/FAILURE)
 Main PID: 9528 (openvpn)
   Status: "Initialization Sequence Completed"
    Tasks: 1 (limit: 1152)
   CGroup: /<email address hidden>
           └─9528 /usr/sbin/openvpn --daemon ovpn-server --status /run/openvpn/server.status 10

May 26 17:11:33 openvpn-reload-bionic ovpn-server[9528]: GID set to nogroup
May 26 17:11:33 openvpn-reload-bionic ovpn-server[9528]: UID set to nobody
May 26 17:11:33 openvpn-reload-bionic ovpn-server[9528]: MULTI: multi_init called, r=256 v=256
May 26 17:11:33 openvpn-reload-bionic ovpn-server[9528]: IFCONFIG POOL: base=10.8.0.4 size=62,
May 26 17:11:33 openvpn-reload-bionic ovpn-server[9528]: IFCONFIG POOL LIST
May 26 17:11:33 openvpn-reload-bionic ovpn-server[9528]: Initialization Sequence Completed
May 26 17:11:49 openvpn-reload-bionic systemd[1]: Reloading OpenVPN connection to server.
May 26 17:11:49 openvpn-reload-bionic kill[9548]: kill: (9528): Operation not permitted
May 26 17:11:49 openvpn-reload-bionic systemd[1]: <email address hidden>: Control process exite
May 26 17:11:49 openvpn-reload-bionic systemd[1]: Reload failed for OpenVPN connection to serve

This error (it returns 1) might confuse users. However, as you can see above, even when the reload command fails the service itself remains active and running. The same happens if we add the '+', but the reload command succeeds (returns 0).

Anyway, I'll prepare a MP to drop the reload support in Groovy while we decide if it worth to SRU a "fix" for this to the supported releases.